Описание системы воркеров для GOLOS

Одним из пунктов нашего последнего дискорда было подготовить описание функционала воркеров для GOLOS.

Рассматривалось две системы. Первая – это система воркеров, которую подготовил КФ в рамках 22 ХФ. Якобы она уже оттестирована и работает, но при обсуждении большинство высказалось в том плане, что она слишком сложная – требуется несколько этапов голосования: сначала для утверждение ТЗ, а потом за оплату. С теоретически точки зрения это хорошо, но по факту усложняем систему для пользования.

Второй момент это системы, который в ходе публичного голосования в чатах GOLOS был отвергнут, это голосование за воркеров делегатами. Среднее мнение по больнице – за воркеров должны голосовать холдеры. Также был отвергнут вариант с утверждением результатов голосования холдеров делегатами, т.е. только холдеры и всё.

В результате, это всё стало походить на воркеров, который @on1x делал для VIZ. Но этот функционал предложено расширить:

1. Введение прокси. Поскольку многие не умеют в код, то логично отдать право голоса тем кто в код умеет, чтобы они голосовали за воркеров. При этом прокси должно иметь алгоритм «протухания», чтобы однажды отданное право голоса не узурпировалось.
2. Оплата за публикацию заявки, чтобы не было спама в систему воркеров, предлагается ввести плату за публикацию заявки, размер которой будут устанавливать делегаты через параметр.
3. Не относящийся к воркерам вопрос, но предложено ввести алгоритм «протухание» и для голосов за делегатов, чтобы стимулировать активность холдеров.

Основная дискуссия развернулась вокруг системы прокси. Кто-то считает, что прокси должен быть один на всё: и на форкеров, и на делегатов, и на рефендум (если такая сущность будет введена в блокчейн). Я же считаю, что достаточно прокси на делегатов и отдельно прокси на воркеров, чтобы не было угрозы создания мегапрокси, который бы мог монополизировать блокчейн. А на референдуме каждый может проголосовать за себя.

В результате я взял описание @on1x по воркерам в VIZ и адаптировал его под GOLOS с внесение туда указанных выше правок.

Документ находится тут:
https://docs.google.com/document/d/1V6wXsWRd2qBbFZJ0e9BM0WqqtQIFM_HMyPldxaOz8v4/edit

Ну, и публикую текст тут:

Вариант воркеров (комитета) GOLOS на по алгоритму из Viz
Фонд воркеров и его пополнение

В GOLOS должен быть создан технический аккаунт committee, который будет являться фондом воркеров. Фонд будет наполняться из двух источников - инфляция и пожертвования (например, направление части средств из фонда референдума). Пожертвования - простые переводы на committee.

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

После направления части инфляции в комитет, оставшаяся доля распределятеся в пропорции (обратите внимание, что пропорции изменились):
Пул делегатов - 15%
Пул вестинга - 10%
Пул публикаций - 75%

Создание заявки в комитет GOLOS

За создание запроса в комитет должна отвечать операция committee_worker_create_request ( по аналогии с viz ссылка на документацию в viz-js-lib), которая должна содержать:
• Ссылку на описание запроса (запрос может быть как в github, так и в самом блокчейне);
• Получатель токенов GOLOS в случае удовлетворения запроса (это может быть как аккаунт обратившегося, так и отдельный escrow аккаунт с мультисигом);
• Длительность голосования за заявку секундах (от 5 до 30 дней);
• Желаемая сумма токенов (максимально возможная);
• Минимально допустимая сумма токенов чтобы заявка считалась удовлетворенной.

Как вы видите, заявка может быть исполнена частично. Заявитель может оставить заявку в виде частичной компенсации за полезную работу постфактум, или, например, план по разработке сервиса с градацией выполняемых задач в зависимости от утвержденной суммы по заявке.

Передумав заявитель может отменить заявку по id, но только до её окончания (должна быть введена операция committee_worker_cancel_request).

Голосование комитета
Самое интересное в данном комитете то, что каждый аккаунт является его участником. В GOLOS каждый участник сможет принять участие в голосовании в рамках своего стека. За это должна отвечать отвечать операция committee_vote_request (пример из VIZ), где по номеру заявки можно проголосовать от -100% до +100%.

Для защиты от атак мелкими стеками консенсус делегатов назначает параметр committee_request_approve_min_percent, отвечающий за минимально необходимое количество голосов для утверждения заявки в комитете. По-умолчанию он равен 10%, что означает — заявка будет отклонена, если проголосует меньшее количество участников всей сети (процент считается от общего объема Силы Голоса). Параметр обновляется раз в день.

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

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

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

В качестве компромиссного варианта предлагается следующая схема протухания прокси с последующим выключением: через полгода сила прокси - 75%, через год - 50%, через 1,5 года - 25% и выключение через 2 года. (если обсуждаемый переход 100% -> 50% безопасен для сети, то выключение с 25% -> 0% априори тоже безопасно).

Восстановление силы прокси происходит при повторной отправки транзакции проксирования в сеть, изменение СГ или другие действия аккаунта на это не влияют.
Аналогичным образом должно быть доработано прокси для делегатов и голосование за делегатов. Прокси голосования за делегатов и голосование за делегатов должны “протухать” по такой же схеме. Это нужно для активизации холдеров на платформе, если ты не в состоянии раз в год обновить прокси - твоё влияние на платформу со временем падает до нуля.

Защита от спама
Для защиты комитета от спама заявками предлагается установить плату за публикацию заявки (публикация заявки при этом осуществляется активным ключом). При создании заявки со счета пользователя на committee отправляется сумма в GBG, которую делегаты должны устанавливать параметром. Параметр обновляется раз в день и по умолчанию равен 100 GBG.

API вызовы
Необходимо доработать библиотеку golos-js по аналогии с библиотекой viz-js-lib (и одноименном пакете npm) там уже доступны все методы для получения данных по комитету.
• get_committee_requests_list — получение массива id запросов в комитет по статусу (0 - ожидает голосования, 1 - отменен заявителем, 2 - не набрал доли голосов для принятия решения, 3 - не набрал минимально необходимую сумму указанную в заявке, 4 - заявка одобрена и производятся выплаты, 5 - выплаты по заявке завершены);
• get_committee_request — получение информации по заявке в комитет по id (второй параметр - возвращаемое количество голосов);
• get_committee_request_votes — получение голосов по заявке в комитет по id.
• должны быть введены дополнительные параметры и команды необходимые для реализации описанного алгоритма.

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