GOLOS·CORE

Очередная версия HardFork 19.0

Golos·Core объявляет о выпуске очередной версии HardFork 19.0, в которой реализованы новые функциональные возможности, а также устранены недостатки предыдущих версий. Обновления поддержаны большинством голосов делегатов.

Важное:
Новые функциональные и технические возможности вносят изменения в правила экономической модели блокчейна. HF-19.0 требует выполнения переиндексации из всех предыдущих версий.

Содержание

Внедрение реферальной программы в блокчейн Golos

(Задача №295)

Решением делегатов было предложено реализовать в HF-19.0 новую функциональную возможность — внедрить реферальную программу привлечения новых пользователей.

Реализация новой функциональности

Реализация реферальной программы предусматривает вознаграждение пользователей (рефереров), пригласивших для регистрации в блокчейн своих друзей или сторонних лиц через социальные сети (просматривая публикации сторонних авторов или размещая собственные посты о блокчейне).
Для реализации реферальной программы в HF-19.0 добавлены следующие операции:
— создание аккаунта-реферала для приглашенного пользователя. В качестве реферера для аккаунт-реферала может быть указан как пользователем, непосредственно пригласивший другого пользователя, так и сторонний аккаунт;
— прекращение действия реферальной программы пользователем-рефералом через выкуп своего аккаунта. Операция позволяет рефералу выкупить свой аккаунт для прекращения выплат рефереру;
— получение информации о пользователе-реферале;
— получение информации о пользователе-реферале по его комментарию или посту.

1) Пример команды для создания аккаунта-реферала с использованием cli_wallet имеет вид:

create_account_referral test "0.200 GOLOS" "0.000001 GESTS" <referral account name> "{}" {"referrer": "test", "interest_rate": 900, "end_date": "2018-09-26T14:00:00", "break_fee": "0.000 GOLOS"} true

где:
referral — имя аккаунта-реферала;
referrer — имя аккаунта-реферера;
interest_rate — процент выплат рефереру от доходов реферала, умноженный на 100. Максимальный процент выплаты рефереру устанавливается голосованием делегатов через операцию update_chain_properties(). Выплаты рефереру осуществляются через назначение реферера бенефициаром в публикуемых постах;
end_date — дата окончания выплат рефереру из доходов реферала. Максимальный срок выплаты рефереру устанавливается голосованием делегатов через операцию update_chain_properties();
break_fee — cумма выкупа рефералом своего аккаунта для прекращения выплат рефереру. Если в качестве сумма выплаты будет указан 0, то аккаунт нельзя будет выкупить. Максимальная сумма выплаты выбирается делегатами через операцию update_chain_properties() по медиане.

2) Пример задания команды для операции по прекращению выплат рефереру имеет вид:

break_free_referral <referral account name> true

3) Для получения информации о пользователе-реферале через cli_wallet используется команда get_account. Для придания аккаунту-рефералу особого статуса в системе в ответ API-метода golos.api.getAccounts() добавлены следующие поля:

    "referrer_account": "test",
    "referrer_interest_rate": 900,
    "referral_end_date": "2018-09-26T14:00:00",
    "referral_break_fee": "0.002 GOLOS"

В период действия реферальной программы для аккаунта-реферала значения полей соответствуют полям из account_referral_options. После прекращения действия реферальной программы поля принимают нулевые значения.

4) Для получения информации о пользователе-реферале по его комментарию или посту в поле beneficiaries добавляется объект с параметрами account= и weight=. Выплата рефереру осуществляются с учетом этих параметров.

Изменение метода начисления вознаграждения кураторам (доработка для штрафного окна голосования)

(Задача №898)

Начало голосования за пост начинается сразу по завершении его публикации. Размер вознаграждения кураторам за голосование зависит от времени голосования. Длительность интервала, отведенного для голосования составляла 30 мин — аукционное окно (англ. auction window), которое открывалось сразу по завершении создания поста. Вес голоса, отданного в интервале этого окна вычислялся по формуле

W = t / (30 × 60) × weight

где:
t — время голосования с момента открытия окна (в секундах);
(30 × 60) — продолжительность окна (в секундах);
weight — вес голоса аккаунта.

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

В версии HF-19.0 (по предложению делегатов) доработан алгоритм для более гибкого начисления вознаграждения кураторам, в том числе:
— стало возможным изменять длительность аукционного окна голосованием делегатов через операцию update_chain_properties();
— стало возможным недостающую (срезанную) часть токенов возвращать либо в пул вознаграждений, либо кураторам, проголосовавшим после закрытия аукционного окна. Решение о том, куда направлять срезанную часть токенов, принимает автор поста.

С этой целью в метод comment_options_operation добавлена опция comment_auction_window_reward_destination, принимающая следующие значения:
to_reward_fund — возврат токенов в пул вознаграждений. При возврате токенов в пул-вознаграждений генерируется виртуальная операция auction_window_reward_operation;
to_curators — возврат токенов кураторам, проголосовавшим после закрытия аукционного окна;
to_author — только для постов, созданных до релиза HF-19.0 (после релиза HF-19.0 выбор данного варианта будет невозможным).

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

(Задачи №№533, 1002)

Делегатами было предложено сократить временные интервалы, отводимые на создание постов, оставление комментариев к посту и голосование, составляющие 5 мин, 20 и 3 с соответственно. Такие жестко установленные интервалы имеют недостаток. Например, за отведенное время 20 с могут появиться до десяти и более комментариев, на ответы которых делегатам приходится затрачивать значительное время.

В версии HF-19.0 появилась возможность изменять длительности интервалов (окон), отводимых на создание постов, оставление комментариев и на голосование, а также возможность изменять предельно допустимое количество постов, комментариев и голосов, оставляемых в течение этих интервалов.

В операцию update_chain_properties, с помощью которой конфигурируется блокчейн, добавлены параметры posts_window, posts_per_window, comments_window, comments_per_window, votes_window, votes_per_window. С помощью этих параметров делегаты могут задавать длительности интервалов, в течение которых разрешается создавать посты, оставлять комментарии и голосовать, а также допустимое количество комментариев и голосов, оставляемых в течение этих интервалов. Значения этих параметров определяются голосованием делегатов через операцию update_chain_properties(), за результаты которых принимаются медианные значения.

В версии HF-19.0 длительность окна для комментирования и допустимое количество оставленных комментариев в течение этого окна составляют 200 с и 10 шт. соответственно. Длительность окна для голосования и допустимое количество отданных голосов в течение этого окна составляют 15 с и 5 шт. соответственно.

Кроме этого в версии HF-19.0 доработан алгоритм, ограничивающий чрезмерную активность пользователей в создании постов, в комментировании и голосовании. Алгоритм позволяет более гибко совершать действия подряд без ожидания завершения 20-секундного интервала до начала следующего действия. Алгоритм работает по принципу «батарейки». Минимальная частота совершаемых действий определяется по формуле

V=window/items

где:
window — длительность интервала, отведенного на отдельный вид действий;
items — количество публикаций, комментариев или голосов, оставленных за отведенный интервал.

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

Пользователь может создавать посты, оставлять комментарии или участвовать в голосовании при условии наличия ресурсов (заряда) в его «батарейке». Алгоритм фиксирует время появления поста и содержимого заряда «батарейки», расходуемого с оставлением каждого комментария к посту или голосованием.

Начисление делегирующему Силы голоса доли от кураторских

(Задача №756)

Количество желающих делегировать Силу голоса невелико. Отчасти это вызвано тем, что делегирующий (инвестор СГ) не получает каких-либо отчислений от кураторских вознаграждений и следовательно не получает вознаграждение вообще.

В версии HF-19.0 добавлена возможность устанавливать процент отчислений инвестору СГ. Куратору, которому делегируется СГ, по результатам голосования за пост отчисляет часть кураторских выплат инвестору.
Алгоритм начисления инвесторам СГ реализован в соответствии со следующими особенностями :
1) Выплата вознаграждений инвесторам происходит одновременно с выплатами кураторам, которым делегировали СГ инвесторы. Инвестору начисляется определенный процент от выплаты куратору. Размер отчисления инвестору определяется по следующей формуле:

Вознаграждение инвестору = (вознаграждение куратора) × (доля инвестора в СГ куратора) × (процент отчислений инвестору)
где:
доля инвестора в СГ куратора = (количество делегированной СГ) / (общее количество СГ куратора)

2) Процент отчислений инвестору назначается непосредственно инвестором. Верхнее значение процента отчислений инвестору устанавливается голосованием делегатов с использованием операции update_chain_properties().

3) В блокчейн добавлена новая виртуальная операция delegation_reward_operation, которая используется для уведомления делегаторов о получаемых ими вознаграждениях за делегированную СГ.

4) Возможность отказа от делегированной СГ получателем (в случае нежелания обмена выплат с инвестором). Для этого была добавлена операция reject_vesting_shares_delegation_operation.
При отказе получателя от делегированной СГ, ее автоматическое зачисление на его баланс получателя не производится. Возврат делегированной СГ делегатору происходит после окончания заморозки длительностью 7 дней.

Возможность пользователя хранить личную информацию в хэш-таблице хранилища в виде key-value

(Задача №924)

Решением делегатов было предложено реализовать в HF-19.0 новую функциональную возможность — предоставить возможность пользователю сохранять нужную ему информацию в хэш-таблице хранилища в виде key-value.

Решение основано на создании нового плагина account_notes, который позволяет аккаунту сохранять необходимую для него информацию в хэш-таблице базы данных системы в виде записей «key-value» в зависимости от настроек конфигурационного файла config.ini. Объем информации для хранения на отдельном Узле (ноде) блокчейна определяется с учетом ресурсов этого Узла.

В плагине account_notes реализован вызов операции set_value_operation, выполняющей создание, изменение и удаление записи в хэш-таблице хранилища. Операция вызывается с полями account, key и value.
Для изменения записи в хэш-таблице операция вызывается с ключом уже имеющейся записи. Для удаления записи в хэш-таблице операция вызывается с ключом уже имеющейся записи и пустым значением.

В конфигурационный файл config.ini добавлены следующие настраиваемые параметры: — an-tracked-accounts — «белый» список аккаунтов. Используется для задания списка аккаунтов, которым разрешено сохранять записи. По умолчанию задается пустое поле, разрешающее хранение записей всем аккаунтам;
— an-untracked-accounts — «черный» список аккаунтов. Содержит список аккаунтов, которым не разрешается хранение записей. По умолчанию задается пустое поле;
— an-max-key-length — максимально допустимое количество символов в ключе. По умолчанию содержит значение 20;
— an-max-value-length — максимально допустимое количество символов в записи. По умолчанию содержит значение 512;
— an-max-note-count — максимально допустимое количество записей для одного аккаунта. По умолчанию содержит значение 10.

В случае превышения в сохраняемой записи установленных граничных значений операция не выполняется. При этом сообщение об ошибке не выдается. Для контроля успешного сохранения информации пользователь должен запросить у Узла его текущую конфигурацию и сопоставить данные сохраняемой записи с граничными значениями этого Узла.
После HF-19.0 стоимость ресурсов бендвича для операций custom_json будет увеличиваться за счет умножения на значение мультипликатора. По умолчанию значение мультипликатора составляет 100. Делегаты могут изменить данное значение путем голосования через операцию update_chain_properties(). Это позволяет пользователям с большим количеством СГ сохранять в хэш-таблице информацию более часто и большего размера в отличие от пользователей с меньшим количеством СГ.

Возможность автора устанавливать размер кураторских отчислений за пост

(Задачи №№324, 677)

В предыдущей версии доля выплаты кураторам была неизменной и составляла 25 % от суммы вознаграждения автору поста. В версии HF-19.0 делегатам предоставляется возможность изменять это значение и устанавливать границы его изменений в интервале от 25 до 100 % включительно.

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

Сумма средств, полученная от процента кураторских отчислений, распределяется между кураторами в соответствии с их весом. Вес куратора определяется по одному из трех алгоритмов:

• Старый алгоритм (bounded) — алгоритм, в соответствии с которым доля кураторского вознаграждения определяется в зависимости от времени голосования и используемой Силы Голоса. В версии HF-19.0 этот метод распределения вознаграждения между кураторами сохраняется.
• Линейный алгоритм (linear). Вес куратора зависит от средств в виде Силы Голоса и не зависит от времени голосования. Устанавливается по умолчанию.
• Алгоритм квадратного корня (sqrt_root). Вес куратора вычисляется с учетом уже имеющихся голосов за пост (отданных другими кураторами) и зависит от времени голосования. Например, если проголосовали 2 куратора с одинаковой Силой Голоса, но в разное время, то второй из проголосовавших получит вознаграждение меньше первого в два раза.

В версии HF-19.0 делегатам предоставляется возможность выбирать один из трех приведенных алгоритмов через операцию update_chain_properties.

В операцию comment_options_operation добавлена структура comment_curation_rewards_percent. С помощью этой операции автор может задать процент кураторских отчислений.

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

Устранение недостатка в ответе API-метода get_account

(Задача №825)

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

В версии HF-19.0 этот недостаток устранен. Был доработан метод get_accounts для корректной записи данных в соответствующие поля при создании поста и комментария. Поле comment_count содержит количество комментариев, а поле post_count — только количество постов.

Изменения в логике системы при долге системы, превышающем 10 %

(Задача №952)

В предыдущих версиях блокчейна в логику системы в части эмиссии GBG был заложен следующий алгоритм:

• если общая стоимость всех токенов GBG, рассчитанная по заложенной в системе цене, не превышает 10 % от стоимости всех токенов GBG и GOLOS, авторам постов начисляется вознаграждение в соответствии со следующей схемой:
  • если долг системы не превышает 2 %, то авторам постов начисляется вознаграждение в виде GBG;
  • если долг системы выше 2 %, но не превышает 5 %, то авторам постов начисляется вознаграждение в виде GBG и GESTS. При этом, при увеличении долга системы от 2 до 5 % включительно количественное соотношение GBG к GESTS пропорционально уменьшается (например, при долге системы 3,5 % вознаграждение начисляется в виде GBG и GESTS в соотношении 1:1. При долге системы 5 % вознаграждение начисляется только в виде GESTS);
  • если долг системы превышает 5 %, прекращается начисление вознаграждения авторам постов. При этом владельцам токенов GBG выплата процентных начислений не прекращается;
• если общая стоимость всех токенов GBG, рассчитанная по заложенной в системе цене, превышает 10 % от стоимости всех токенов GBG и GOLOS, выплата процентных начислений владельцам токенов GBG продолжается без прекращения эмиссии этого вида токенов.

В версии HF-19.0 внесены изменения в логику системы в части эмиссии GBG. Изменилась работа алгоритма при долге системы, превышающем 10 %. Измененная часть алгоритма:

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

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

Сброс понижения силы голоса на другой аккаунт после восстановления учетной записи

(Задача №971)

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

В версии HF-19.0 введена доработка, обеспечивающая блокировку операции по выводу средств со счета аккаунта в случае потери личного ключа или несанкционированного доступа к личному ключу аккаунта.
Доработана операция withdraw_vesting. Операция по выводу средств длится в течение 13 недель. Во время выполнения этой операции с частотой один раз в семь дней выводятся средства в виде GESTS. После восстановления учетной записи (аккаунта) автоматически отменяется операция set_withdraw_vesting_route. Удаляются все выводы из расписания. При этом все выплаты в GESTS восстанавливаются за исключением той части средств, которая уже до восстановления учетной записи была выведена в качестве выплат.

Оптимизация расчета ожидаемых выплат автору и кураторам

(Задача №976)

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

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

Возможность постраничного просмотра и сортировки результата, получаемого от API-запроса

(Задача №981)

Просмотр списка проголосовавших за пост выполняется через API-запросы вида social_network::select_active_votes. Количество проголосовавших может быть чрезмерно большим и поэтому просмотр списка голосов в виде «лайков» или «дизлайков» может занимать длительное время. В предыдущей версии блокчейна голоса появлялись в списке в соответствии с их появлением в окне голосования без учета их веса, что затрудняло анализ результатов голосования.

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

Устранена ошибка в подсчете количества личных сообщений

(Задача №990)

Пользователь имеет возможность получать статистическую информацию о количестве поступающих личных сообщений от аккаунтов, в том числе от закрепленного с ним в переписке (англ. pinned), от неизвестного (англ. unknown) и заблокированного (англ. ignored) аккаунтов. В предыдущей версии блокчейна после удаления пользователем сообщений от одного из этих типов аккаунтов, данные о количестве личных сообщений от другого типа аккаунта могли быть также изменены и быть некорректными (например, отображать максимально возможное значение). В версии HF-19.0 доработаны счетчики, обрабатывающие количество поступающих пользователю личных сообщений, для каждого типа аккаунтов. Доработка обеспечила корректный подсчет личных сообщений пользователя, поступающих от аккаунтов всех типов.

Используемая терминология

Аккаунт (англ. account) — хранимая в системе учетная запись пользователя для его опознавания (аутентификации) и предоставления доступа к его личным данным и настройкам.
Аккаунт-реферал — аккаунт, созданный для приглашенного в систему пользователя (реферала) другим пользователем (реферером) этой системы.
Медианное значение — значение, определяемое выборкой из середины множества чисел, расположенных в определенном порядке (по убыванию или по возрастанию). Например, медианное значение множества {8, 8, 7, 2, 1} равняется 7, так как это число находится в середине множества. Если множество состоит из четного количества чисел, то результатом является полусумма двух соседних значений. Например, медианное значение множества {7, 5, 3, 1} равняется 4.
Пост (англ. to post — размещать, публиковать) — любая статья или запись на веб-странице, содержащая название, перечень ключевых слов и непосредственно текст.
Реферал (англ. referral) — пользователь системы, приглашенный и зарегистрировавший в системе по рекомендации другого пользователя этой системы.
Реферер (англ. referrer) — пользователь системы, привлекающий в данную систему других пользователей.
Токен (англ. token) — внутренняя платежная единица, предназначенная для представления цифрового баланса в некотором активе (не является криптовалютой).