goloscore

6 лет назад

Новости Golos•Core. HardFork 19.0: Новые возможности блокчейна

Добрый день!

Уважаемые делегаты и члены коммьюнити!

В Wiki.golos.io сегодня была опубликована очередная версия HF 19.0.

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

Внедрение реферальной программы в блокчейн 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= < referrer name> и weight=<referrer_interest_rate>. Выплата рефереру осуществляются с учетом этих параметров.

Изменение метода начисления вознаграждения кураторам (доработка для штрафного окна голосования, задача №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)

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

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

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

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

V=window/items

Где:
window — длительность интервала, отведенного на голосование;
items — количество комментариев или голосов, оставленных в интервале голосования.

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

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

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

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

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

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

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

Процент отчислений инвестору назначается непосредственно инвестором.
Верхнее значение процента отчислений инвестору устанавливается голосованием делегатов с использованием операции update_chain_properties()`;
В блокчейн добавлена новая виртуальная операция delegation_reward_operation, которая используется для уведомления делегаторов о получаемых ими вознаграждениях за делегированную СГ;
Возможность отказа от делегированной СГ получателем (в случае нежелания обмена выплат с инвестором). Для этого была добавлена операция 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)

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

В операцию update_chain_properties, с помощью которой конфигурируется блокчейн, добавлены параметры min_curation_percent и max_curation_percent. С помощью этих параметров делегаты могут устанавливать предельно допустимые значения процента кураторских отчислений. Эти значения определяются голосованием делегатов, за результаты которых принимаются медианные значения. В конфигурационный файл config.hpp добавлены константы STEEMIT_MIN_CURATION_PERCENT и STEEMIT_MAX_CURATION_PERCENT для задания минимального и максимального их значений по умолчанию, которые составляют 25 и 95 % соответственно.

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

Устранение недостатка в ответе API-метода get_account (задача №825)

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

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

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

https://t.me/goloscoretc (решение технических вопросов, связанных с работой блокчейн, нод, api и др.)
https://t.me/joinchat/BLwf_A118xQ57nsM1Q4MPA (канал для вноса предложений от комьюнити, обсуждение перехода на кодовую базу EOS)
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: @korpusenko, @andreypf, @maslenitsa, @muhazokotuha, @zxcat, @annaeq, @anazarov79, @kaynarov, @s-medvedev