Воркеры. Какой вариант предпочтительнее?


С точки зрения простоты и эффективности меня вполне устраивает вариант воркеров а ля VIZ.
Это рабочее и опробованное решение. В отличии от трудновоспринимаемого варианта от КФ. Птому всё, что напаписано ниже, параллено просматриваетстся и сверяется с текстом «Вариант воркеров (комитета) GOLOS по алгоритму из Viz» предоставленным @litrbooh.

В данном посте рассматриваем «Создание заявки в комитет GOLOS»

В отличии от VIZ, где комитет является отдельной сущностью и к заявке надо давать ссылку на какой-то ресурс с описанием, в Golos уже всё имеется. Только надо немного доточить функциональность и интерфейс. Поэтому предлагается третий вариант.

Что требуется для заявки в VIZ?
https://control.viz.world/committee/create/

Требуется специальная запись в блокчейн с указанием:

  • ссылка на описание
  • получатель выплаты
  • желаемая сумма токенов
  • минимальная сумма токенов
  • длительность голосования
    для этого существует операция committee_worker_create_request

Что имеем мы?

Ссылка на описание.
В бч Golos имеется основная единица: пост (comment), имеющая достаточно широкую функциональность. Именно пост и может быть и заявкой в комитет, и собирать голоса. В плюс и минус до 100% в обе стороны. Также, как и на VIZ.

Ссылка на описание таким образом не требуется. Пермлинк является id заявки. Про порядковый же номер заявки в комитете я упомяну ниже.

А что для этого требуется? В параметрах поста имеется опция mode, которая обычно принимает значения:
"mode": "first_payout"
"mode": "archived"

Расширяем принимаемые значения на
proposal - заявка подана
revoke - заявка отозвана
refusal - заявка отклонена
is_paying - происходит выплата
completed - завершена

Теперь пост сможет принимать тип всех стадий прохождения заявки.
При этом посты с каким-либо типом заявки не участвуют в распределении пула наград. Это должно обрабатывается блокчейном, видимо также, как пост с указанием «Отказ от выплат»
Кроме того, первым тегом/категорией нужно автоматически указывать committee.
Это потребуется позже, для вынесения состояний заявок комитета на отдельную вкладку интерфейса. Пост оформленный не по утверждённому шаблону не должен рассматриваться как заявка.

Таким образом новая операция (committee_worker_create_request) для создания заявки - не требуется, не требуется и правка библиотек.
Хотя потребуется операция изменения mode с proposal на revoke, при отзыве заявки создателем. Хотя можно воспользоваться операцией
{
"roles": ["posting"],
"operation": "delete_comment",
"params": [
"author",
"permlink"
]
}
доработав её, чтобы при операции удаления поста-заявки просто в посте бы менялось mode на revoke (до завершения срока заявки).
А также, если пост-заявка подписывается постинг-ключём автора, то отзыв должен, возможно, делаться его активным ключом. Смена на остальные типы происходит в блокчейне виртуальными операциями.

Получатель выплаты.
В настоящее время имеется возможность (но отсутствует в интерфейсе) указание бенефициантов поста. С помощью этой функции можно как раз устанавливать получателя выплаты по заявке. Мало того, в отличии от VIZ, этих получателей может быть несколько в случае коллективной работы. Также создатель заявки-техзадания может оговорить с воркером процент и оставить себе, скажем, 10-15% за техзадание и контроль, указав воркера бенефициантом на 85-90% от суммы заявки. Или если заявку подаёт сам воркер, то бенефициантов не указывает или, опять же, указывает участников команды.
Таким образом мы имеем уже готовую, очень гибкую систему распределения выплаты по заявке.
С получателями выплат разобрались.

Желаемая сумма токенов.

Это, по сути, максимальная сумма заявки/выплаты.
Опаньки, а в посте-заявке для неё уже есть место:
"max_accepted_payout": "1000000.000 GBG"
Вопрос только в возможности указывать нужные токены, в которых ожидается выплата.
На VIZ проще. Там токен один, поэтому такой проблемы нет. Но мы то должны это учитывать.
Кто-нибудь озадачивался этим вопросом? Если начнут печататься GBG, то и оплата может производится в них.

Минимальная сумма токенов.

С этим сложнее. В каком поле хранить? Добавлять новое? Но зачем всё ещё больше усложнять? Есть два простых способа.
а) задействовать под хранение этой суммы незадействованное поле поста-заявки, в частности
"curator_payout_value": "1.138 GBG"
с поправкой на возможность указать другой токен. Или какое-то другое.
Ведь, как ранее я указал, за пост не будут проводится выплаты и никакие кураторские начисляться не будут. Хотя процент кураторских и какие-то другие дефолтные значения в него могут заносится, так как это не мешает и ни на что не влияет. И не потребует дополнительных правок в коде.
б) у нас имеется «comment_options_add», дополнительные опции в custom к посту, где хранятся бенифициары и пр. Вот туда можно поместить любую дополнительную информацию по заявке. В том числе и порядковый номер заявки в комитете, сопоставляя его с id поста или пермлинком.

Вопрос решён?

Длительность голосования.

Опять же можем использовать одно из полей, которые вроде никогда не используются. Или не будут использоваться в посте-заявке. Точнее будут использованы под свои нужды.
"cashout_time": "1969-12-31T23:59:59"
"max_cashout_time": "1969-12-31T23:59:59"
Указанная длительность заявки при создании поста добавляется к дате создания (created) и заносится во второе из вышеуказанных полей. Длительность указывается в любом виде, на control.VIZ.world например, указывается в днях, но можно указать 5.2 дня. И это пересчитается в секунды и через такое время заявка будет завершена.

Можно хранить время окончания ожидания в max, а время начала реальной выплаты заносить в cashout_time. По сути это должно быть одно и то же время. Но, в случае отсутствия средств в комитете, оно может задержаться. Но по окончанию срока ожидания пост переводится, согласно результатам голосования, в refusal или is_paying.
В случае refusal значение остаётся дефолтным: "cashout_time": "1969-12-31T23:59:59"
А для окончания реальной выплаты есть last_payout.
После окончания выплаты пост переходит в mode completed. Или остаётся refusal.

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

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

Предлагаю обсудить данное предложение, возможно что-то я не учитываю.
Тем временем я подготовлю продолжение по разделу «Голосование комитета», а также по интерфейсу создания заявки.


Comments 16


Фонд БОД сделал репост.
Ваше творчество в ленте.
Наша лента в telegram.
)
Вы являетесь участником проекта БОД, поэтому все ваши посты
размещаются в ленте репостов фонда. Если не желаете получать
апвот фонда и этот комментарий, ставьте тег nobod.
03.09.2019 05:20
0

Идеально!

03.09.2019 07:20
0

@retroscope , мешать посты в заявками это очень странная тема. Как на счет спама в комитет?

03.09.2019 08:07
2

@litrbooh, почему мешать?
Во-первых, в заявке должна быть ссылка на пост. Где будет размещён этот пост? Половина заявок на визе снабжен а ссылками на посты в Голосе.
Во-вторых, посты-заявки в интерфейсе golos.id могут фильтроваться и размещаться на отдельной вкладке или вообще быть доступны по переходу через меню, как внутренняя биржа.
В-третьих, если имеется готовый механизм создания и голосования, то зачем делать ещё один параллельно, дублируя тот же функционал?

Насчёт спама: Протеину не проблематично подправить свой скрипт и заспамить комитет заявками. Причём, планируемое мной предложение о блокировании написания автором/воркером новой заявки до закрытия старой легко обходится его ботнетом.
Так же не думаю, что кто-то начнёт писать посты, как заявки, без получения с них авторских.
Кроме злобных вредителей. :-)

03.09.2019 08:39
7

@retroscope , потому что это разные сущности и разные алгоритмы голосований и подсчета результата

03.09.2019 08:42
2

@litrbooh, подсчёт и будет выполняться по разному.
Какая разница, что будет в ведре: малина, помидоры или рыба.
Форма одна, содержание и переработка разная.
Вёдра с рыбой ставим в отдельный сарай. :-)

Я так и знал, что возражения будут по форме, а не по сути.

03.09.2019 09:43
7

@retroscope как в этом варианте учитывать голосвание прокси?

13.09.2019 14:58
0

@blockchained, в целом, я придерживался той же стратегии, что предлагал @litrbooh в варианте по VIZ.
Нюансы, в случае такого решения, добавляются несколькими дополнительными строчками кода. В частности, если при обычном голосовании в rshares заносится вес СГ voter'a пропорционально percent, с учётом всей делегированной ему СГ, то в случае заявки, с указанием mode: proposal в rshares заносится только личная СГ вотера, а в случае, если вотер является прокси, то заносится СГ с учётом проксированной ему СГ. Один if и занесение либо делегированной, либо проксированной СГ. В if может быть ещё добавлен и параметр консенсуса, если таковой будет реализован, можно ли использовать прокси при голосовании за заявки. Как и: можно ли использовать делегированную СГ для этой же цели.

Все доработки несут минимальное изменение в коде. Но лучше, конечно, чтобы это предложение посмотрел и оценил воркер. При одной и той же оплате.

14.09.2019 11:40
7

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

14.09.2019 12:00
7