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

С точки зрения простоты и эффективности меня вполне устраивает вариант воркеров а ля 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, только на вводе у него будут браться данные из поста-заявки и результаты завершения заносится туда же. Данных этих не много и больших переделок, также думаю, вызывать не должно.

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