EOS или не EOS, часть 5.1: Ещё изменения в форке EOS (куча идей)

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

1. Бесплатные и быстрые транзакции:

Плюсом Голоса и Steem является то, что транзакции здесь быстры и не имеют комиссий - согласен с @lindsay в этом плане.
Считаю, что необходимо сохранить это преимущество после перехода на EOS форк.
Но транзакции бывают разными. Разделим их следующим образом:

1. С минимальной нагрузкой на сеть (переводы между пользователями, апвоты, репосты, обновление информации о приложении в EOS форке, воркеры, принятие решений об обновлении DApp или сети, делегирование/отмена СГ, понижение СГ и т.п.);
2. Со средней нагрузкой (Публикация объекта (Сейчас это посты), добавление комментария к объекту, custom_json, Custom_binery, репост с комментарием и т.п.);
3. С высокой нагрузкой: Транзакции, содержащии смартконтракты, транзакции произвольные, создаваемые смартконтрактами, и не относящиеся ни к одному из перечисленных выше типов, SEND_IPFS транзакции, так как они требуют взаимодействия с IPFS и т.п.

Транзакции, содержащие операции первого типа должны быть бесплатными; Второго - иметь комиссию; Третьего - ещё большую комиссию, платёж за размер транзакции или использование части ресурсов сети в соответствии с имеющемся аналогом СГ.

При этом платежи должны быть самыми быстро выполняемыми. На втором месте - апвоты и репосты без комментариев, на третьем - Воркеры и обновление приложений в сети, принятие решений об изменениях в DApp или сети, на четвёртом что-то ещё... И так далее.

2. Воркеры:

О них @goloscore тоже писали.
Должен быть инструмент, вознаграждающий разработчиков за выполняемую работу. Это повысит мотивацию разрабатывать что либо для сети или DApps.

Типы запросов:

1. Предзапрос на выполнение работы. В этом случае разработчики со своего аккаунта публикуют заявку, где есть заголовок проекта, его описание, github, где будет идти разработка, заказчики (Те, кто придумал идею), список инвесторов и статус взаимодействия с ними, запрашиваемая цена и срок разработки. Также можно сделать поле со списком кошельков, которые получат средства, с указанием цен у каждого.
   Те, кто согласны, отмечают этот проект. Если большинство делегатов/избранных пользователей для Воркеров выбирают проект, разработчики получают токены из фонда, но ...
   Они блокируются смартконтрактом. Только после окончания разработки будет разморозка. При этом на момент окончания подбираются случайным образом гаранты и, если делегаты не хотят отдавать токены, хотя проект создан, оспаривают это решение, после чего средства переводятся на кошелёк/кошельки разработчиков.
   средства для Воркеров могут появляться из эмиссии новых токенов, из комиссий или прибыли от инвестиций в приложения.
2. Заявка на получение средств после разработки проекта:
   Поля такиеже, как в предыдущем варианте.
   Но смартконтракта нет - в случае одобрения токены сразу переводятся аккаунту/аккаунтам.

Важно:

Воркеры должны быть реализованы как на уровне Блокчейна, так и на уровне DApp.
То есть в API, позволяющем создавать децентрализованные приложения, должна быть прописана возможность создания всех условий для Воркеров внутри приложения.
Тогда, например, golos.io могло бы независимо от сети форка развиваться.

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

Что ещё нужно внедрить в форк:

Вставлю сюда то, что не требует написания большого числа букв:

1. Обязательно надо сделать возможность отправки Custom_json транзакций, так как они позволяют создавать большую гибкость. Не знаю, есть ли они в EOS, но с ними будет лучше. Это позволит тем, кто не умеет делать смартконтракты, создавать транзакции с произвольными данными, не обучаясь дополнительно.
   Например, с их помощью такой разработчик сможет добавить, например, статистическую информацию из базы данных для взаимодействия другими пользователями через API.
2. Готовая реализация шифрования одной функцией в API GOLOS/EOS, чтобы не приходилось разработчикам вовне искать то, как зашифровать/расшифровать данные ключом пользователя (Этот вопрос в чате EOS задавал @captain);
3. Распределение технических токенов в зависимости от СГ хорошая идея - приведёт к массовым закупкам GOLOS - стоит реализовать.
4. Custom_binery. @on1x писал в чате Viz, что этот тип сейчас не используется на практике.
   Думаю стоит его перенести в форк, найти практическое применение (Добавление напрямую в блокчейн небольших файлов, например, логотипа проекта, хелперов для ускорения работы DApp за счёт наличия в готовом виде части функционала в бинарном виде и т.д.) и улучшить:
5. Добавить возможность добавления не только строк;
6. Разработать методы и примеры в API.

Пока всё:

Есть кое что ещё, но это в части 5.2, которую опубликую сегодня же.
Слишком много букв вышло.
Буду благодарен за отклик и ваше мнение по поводу написанного.