Добрый день!
Мы продолжаем информировать сообщество о текущей разработке Golos•Core. До завершения работ над ХФ осталось не так много. В статусе Done находится 27 из 37 декомпозированных задач.Ход работ отображен на нашей Канбан-доске.
Про делегирование
В рамках работ над ХФ 18 мы разрабатываем экономически важный инструмент - делегирование Силы Голоса. Этот инструмент дает возможность делегировать Силу Голоса другому аккаунту на фиксированный промежуток времени. Основная идея заключается в возможности аккумулировать Силу Голоса мелких аккаунтов в один общий аккаунт. Подробное описание приведено в этом посте.
Однако, как любое важное изменение экономики Голоса, данная фича несет в себе риск злоупотребления. Пользователь @ropox обратил наше внимание на то, что эта фича может нецелево использоваться (указал в нашей задаче на разработку делегирования). Смысл злоупотребления заключается в том, что пользователь сначала голосует полностью всей Силой Голоса от своего аккаунта, далее передает всю Силу Голоса другому аккаунту, который также голосует и возвращает делегированное (естественно оба аккаунта могут принадлежать одному собственнику). На эту операцию (с возвратом) требуется 7 дней и 1.5 часа. Выгода по сравнению с использованием одного аккаунта составляет около 40% (в rshares, расчеты можно просмотреть по ссылке).
Мы проанализировали два возможных решения данной проблемы.
Вариант 1 (предложен @ropox)
При делегировании менять voting power (батарейку) аккаунту-получателю по предложенной формуле: delegatee.voting_power = (delegated.vestings x delegator.voting_power + delegatee.vestings x delegatee.voting_power) / (delegated.vestings + delegatee.vestings)
Т.е. мы перемножаем делегируемую силу Голоса с зарядом батарейки 2-х аккаунтов и далее изменяем заряд батарейки у пользователя, кому делегировали. Сложности при данной реализации заключаются в том, что система начнет вести себя нетипично , т.е. voting power будет меняться визуально, и у получателей возникнут вопросы по резкому изменению.
Вариант 2 (предложение Голос Кор, @zxcat)
Добавить проверку на размер батарейки делегирующего аккаунта и ограничить объем передаваемой Силы Голоса процентом заряда батарейки его аккаунта. Это вариант сводит на нет потенциальное преимущество второго аккаунта в части voting power и не приводит к вышеуказанным рискам, а также проблемам с расчетами.
Как Golos•Core мы считаем второй вариант оптимальным для реализации. При этом готовы рассмотреть альтернативные предложения решения проблемы от делегатов, программистов, других заинтересованных в решении вопроса лиц.
Про эксплорер
В связи с отказом jesta от дальнейшей поддержки эксплорера Голоса мы продолжаем дорабатывать собственный инструмент - explorer.golos.io. В планах стоит исправление существующих багов к моменту выпуска релиз-кандидата ХФ 18.
Среди важных задач, которые должны быть выполнены к этому сроку: создание постраничного просмотра операций в аккаунте, подробный вывод об операциях в информацию об аккаунте, исправление отображения виртуальных операций.
Данный продукт должен стать удобным инструментом, востребованным не только биржами, но и всем сообществом.
Каналы коммуникации с 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. Заходите на страничку https://golos.io/~witnesses и проголосуйте за делегата Golos•Core
Спасибо за внимание и хорошего дня!
С уважением,
Команда Golos•Core @kotbegemot, @korpusenko, @abgvedr, @andreypf, @epexa, @muhazokotuha, @timurku, @zxcat, @mariadia
_cr.jpg)
Вариант 2 выглядит отлично.
я тоже за второй
Вы с ним общались? Он подтвердил, что забросил и не будет больше поддерживать свой проект? На Голосе он давненько уже не был.
@aleos Всё так! Здесь можно посмотреть его официальный ответ:
https://steemit.com/witness-update/@jesta/witness-roadmap-potentially-for-jesta-in-2018#@jesta/re-epexa-re-jesta-witness-roadmap-potentially-for-jesta-in-2018-20180228t082207831z-2018228t151525414z
Благодарю за ответ, @epexa ) А вы новый разраб в Голос-коре? раньше не видал вас тут. Михаил nemo уже не работает с вами? давненько не видать его что-то.
Ваш пост поддержали следующие Инвесторы Сообщества "Добрый кит":
midnight, gromkirill, semasping, gans91, arturio777, polyakov, oksana0407, irimeiff, aleos, boliwar, alexxela, rastabandito
Поэтому я тоже проголосовал за него!
Узнать подробности о сообществе можно тут:
Разрешите представиться - Кит Добрый
Правила
Инструкция по внесению Инвестиционного взноса
Вы тоже можете стать Инвестором и поддержать проект!!!
Если Вы хотите отказаться от поддержки Доброго Кита, то ответьте на этот комментарий командой "!нехочу"
dobryj.kit теперь стал Делегатом! Ваш голос важен для всего сообщества!!!
Поддержите нас:
Вариант 3 - при отмене делегирования СГ возвращается не через 7, а через 11 дней
( 7 + 40% от 7 дней )
да, этот вариант тоже просчитывали, хватает 10 дней, чтоб свести на нет эффективность читерства.
но увеличение срока сделает делегирование менее привлекательным и для обычных пользователей, которые делегируют СГ без намерения воспользоваться багом.
когда мы понижаем СГ, то при апвотах весты учитываются текущие.
а что если при делегировании, а точнее при отзыве перестать учитывать те весты, которые отзывают?
я апнул первым аккаунтом на 1к СГ, далее передал СГ второму аккаунту так же с СГ 1к... и апнул уже 1+1к СГ... окай... один раз я так сделал. теперь отзываю СГ...
вот тут внимание...
я так понял, что планируется, что при отзыве на втором аккаунте так и остается 2к СГ? и он продолжает им апать... а что если при отзыве эти 1к СГ "потерять" (как в сейфе, когда выводишь).
тогда я на какое то мгновение 2к СГ с двух аккаунтов превратил в 3к СГ, но потом целую неделю у меня в распоряжении не 2к СГ, а только 1к, так как на первом по нулям, а со второго аккаунта я отозвал эти самые 1к СГ.
если же делать ограничения по "батарейке", что непонятно, как передача вестов изменяет батарейку, то разве не теряется основной посыл делегирования СГ... сами же написали
обращаю внимание, что сравнительно недавно долгое время некто регистрировали аккаунты через голос ио еще когда начисляли по 5 СГ. фактически у кого то есть почти бесплатная бот сеть с халявными СГ.
введение этого функционала позволит этой группе слить СГ в один аккаунт, равно как понижение СГ на вывод требует больше чем 5 СГ на аккаунте.
нет, при отзыве СГ сразу уходит со второго аккаунта и переходит в expiring-состояние, из которого вернётся на делегировавший аккаунт через неделю.
передача вестов изменяет «батарейку» получателя только в первом варианте решения проблемы читерства.
во втором варианте «батарейка» ограничивает, сколько СГ делегирующий может делегировать в данный момент. никто не помешает ему зарядить «батарейку» до 100% и делегировать всю СГ без остатка
в нашей реализации делегирования, как и в стиме, есть ограничение на минимальное количество СГ, которое можно делегировать. делегировать разрешается не менее account_creation_fee×10 СГ.
но при понижении стоимости регистрации аккаунта проблема действительно может возникнуть.
я не смог разобраться в ваших вычислениях, поэтому предположил, что атака будет следующей
у меня есть один аккаунт на 1к СГ... я за 10 минут делаю 200 апвотов на заранее подготовленные комменты и сажаю батарейку аккаунта до нуля. далее у меня есть второй аккаунт на 1к СГ, я ему делегирую 1к и у него уже 2к СГ и им так же за 10 минут делаю 200 апвотов на подготовленные комменты. сажаю батарейку до нуля и отзываю делегированную СГ. через 5 дней у меня восстанавливается батарейка на акаунтах, но есть только 1к СГ на втором, так как у первого СГ в ауте находится, и им апаю еще два дня.
так вот такая схема дает всего лишь 68% от если бы я просто равномерно через каждые 36 минут обоими аккаунтами апал всю неделю специально подготовленные комментарии.
у меня -32%, у вас +41%... и откуда 1796 апвотов у читера?
в модель перенесён код расчёта
rsharesиvoting_power, выполняемый на ноде. за 200 апвоутов «батарейку» не посадить, даже когдаvoting_powerопускается до 50 (0.5%), можно проголосовать ещё 50 раз. весь процесс голосования виден в консоли браузера при запуске скрипта модели. там есть иrshares, иvoting_power, и задержка между апвоутами.сама модель построена немного иначе, у «читера» N СГ, у «сообщника» — 0. первый делает 898 голосов, делегирует СГ второму, тот делает столько же, и СГ возвращается. на весь цикл требуется 7 дней и полтора часа. эти полтора часа как раз уходят на 1796 голосов.
в вашей модели апвоутов должно быть больше, т.к. после 200 непрерывных апвоутов заряд «батарейки» будет около 36%
благодарю за ответ.
не подскажете по какой формуле происходит понижение батарейки?
см. переменную
usedPwr— на столько уменьшится «батарейка»:this.vp += regenerated - usedPwr;с её же помощью вычисляются
rsharesапвоута:let rshares = me.effectiveVests * usedPwr / GLS_100_PERCENTв коде ноды это переменная
used_power.модель / vote_evaluator
понял, у меня как раз эта формула и была в питоне.. used_power и user_power меня внутри своего кода чутка запутали.
кстати, провел "атаку". разрядил один из аккаунтов до 0 батарейки. получилось смоделированное кол-во апвотов. и начал задаваться вопросом, а зачем делать сложности во втором варианте решения проблемы и делегировать часть СГ от процента батарейки, когда можно просто поставить возможность делегировать любую СГ только при 100% батарейке?
ибо и в втором варианте можно злоупотреблять. сложно, но можно, просто устроив карусель... условно наапать до 50% батарейки, передать половину СГ, наапать там, отозвать, передать намбер 3, наапать, отозвать, передать и растянуть это по временным параметрам и кол-ву участников карусели.
технически можно злоупотреблять и сейчас, без делегирования, а просто играя на понижении СГ. карусель гигантская, выхлоп спорный, но больше нуля. (я это уже описывал в блоге). еще недельку подумаю, ибо с переходом на линейку + добавление атаки через разрядку батарейки аккаунта возможно всё будет проще в плане текущего злоупотребления.
сложностей особых нет, а вот ограничение «только при 100%» по юзабилити ударит. защищаясь от читеров не стоит портить жизнь остальным пользователям.
это маловероятно, потому что получаемые
rsharesэто всегдаvoting_power * vests, и если это значение просуммировать по всем аккаунтам, оно остаётся постоянным*, вне зависимости от делегирования (во 2м варианте). можно голосовать и делегировать неэффективно, тогда оно будет ещё меньше. но больше — не получится.проверьте вашу модель с каруселью, на нескольких циклах, вероятнее всего вы после первого цикла не возвращаете её в начальное состояние, поэтому получается небольшой выигрыш. иными словами, при равномерном голосовании «батарейка» остаётся на 100%, а при «читерском» в конце цикла она может оказаться <100%, и эта разница
voting_powerувеличивает полученныеrshares.на счёт злоупотребления понижением СГ —интересно будет почитать
Второй вариант хорош и интуитивно понятен.
без которого (+сообщество) и хф бы никакого не было
ну и roadscape еще) на данный момент самый удобный и постоянно работающий эксплорер где?) - правильно, у @vik ' а))
Пересчет же будет только один раз в момент делегирования?
это да, но voting_power аккаунта может внезапно поменяться на десятки процентов. какие-нибудь скрипты после такого вероятно отвалятся.
дополнительно для варианта 1 можно устроить «атаку делегированием»:
в результате уменьшим батарейку тому, кому делегировали
Да и атака делегированием, напоминает больше мазахизм.
это да, ущерб атакующему больше, чем атакуемому. но возможность сделать назло всегда найдёт своего пользователя
Хорошо, как нас счет рекурсии при делегировании в вашем варианте. Например:
У меня батарейка 60%, я делегирую 60% СГ на 1 аккаунт.
Батарейка остается 60%, я делегирую ещё 60% от остатка на 2ой аккаунт и т.п.
Это несколько усложнит операцию, но если это все автоматически делается, то читеру пофигу.
Если брать второй вариант, тогда при делегировании, нужно пересчитывать батарейку делегирующему. Чтобы если делегировал 60% и батарейке 60%, то батарейка должна обнулиться.
не-не, ограничитель не так работает.
У аккаунта есть:
vesting_shares— собственная СГdelegated_vesting_shares— сколько он делегировалreceived_vesing_shares— сколько ему делегировалиПри делегирование собственная СГ не меняется, изменяются эти дополнительные поля.
Максимальное количество СГ, доступное к делегированию будет считаться относительно собственной СГ. Если часть уже делегирована, то она будет вычтена из максимума.
Ну, тогда такой вариант кажется оптимальным.
В результате у тебя убывает СГ в зависимости от VP. Само делегирование на VP не влияет, оно влияет на то, какой процент СГ ты можешь передать.
Всего или за один раз? Если всего, то ОК.
Если у кого-то не открывается explorer.golos.io - не удивляйтесь. Он попал под ковровые блокировки РКН.
У меня норм открылся, сразу.