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

Здравствуйте.

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

Продолжаю публиковать идеи, которые начал писать здесь.

3. Схема получения ресурсов сети форка EOS:

Сразу скажу, что буду называть аналог СГ в форке "СГ", но он может называться иначе.

В зависимости от имеющейся СГ пользователь может получить определённый процент ресурсов сети.

Пример:
Всего аккаунты имеют 50 МЛН СГ. У вас - 5000. Значит, что вы имеете право на 0,01% ресурсов сети.

Допустим, что всего доступно 10 Терабайт диска и 3,2 ТБ оперативки.
Это значит, что ваш аккаунт при 5000 СГ может получить лишь 1 ГБ диска и 320 МБ оперативной памяти.

Соответственно, при увеличении СГ у вас будет больше ресурсов.
Если же общее количество СГ станет, например, 60 МЛН, а у вас изменения будут всего на 400 СГ (5400), вы получите всего 0,009%, т. е. меньше, чем раньше - надо будет докупить СГ, чтобы получить столько же или больше.

Если ресурсов не хватает, есть 2 варианта:

Докупить токенов и вложить в СГ;
Выбрать режим побайтной покупки ресурсов. В этом случае вы будете платить за затрачиваемые сверх максимума токенами.

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

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

Делегирование:

Тут надо смотреть:

С одной стороны это хорошо: пользователи, купив токены, могут вложить в СГ, а затем делегировать аккаунтам приложений, которыми пользуются. Это будет позитивно влиять на курс и на доступные у приложения ресурсы;
Но с другой стороны это будет увеличивать общее количество СГ довольно быстро. Значит, некоторым приложениям придётся часто, если не постоянно, покупать токены для перевода в СГ.

ценообразование побайтной оплаты ресурсов:

Цена должна быть фиксирована, устанавливаться 85% от общего количества предоставляющих ресурсы пользователей.

О заработке владельцами ресурсов:

С побайтной покупкой всё, думаю, понятно. А как же оплачиваются ресурсы при использовании приложениями СГ?
Всё просто: 75% эмиссии токенов начисляется пропорционально предоставляемым DApps ресурсам.

И ещё:

Должна быть внедрена формула такая, чтоб популярные среди пользователей приложения могли иметь меньше СГ и тратить меньше токенов для обладания нужным количеством ресурсов, чем непопулярные DApps.
Пример:

Непопулярное приложение, имеющее 5000 СГ из 50 000 000 - имеет 0,.01% ресурсов;
Популярное приложение, имеющее те же 5000 СГ из 50 МЛН - 0,012% (+20% к количеству ресурсов);

Непопулярные приложения с плохойй репутацией могут иметь штраф, т.е. вместо 0,01% иметь 0,007%, что компенсирует расходы на популярные.
Также меньшее количество процентов могут получать платные приложения, которые могут увеличивать постоянно СГ за счёт расходов пользователей, но делать так или нет - надо думать..

Плюс такого варианта в том, что

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

4. Батарейка в форке EOS.

Она никак не связана там с апвотами, а выполняет иную функцию.
Это батарейка, говорящая приложению о том, сколько процентов от доступной нагрузки он может использовать.
Я не знаю, чем измеряется нагрузка, поэтому не могу привести пример точный. Но виртуальный - вполне.

Допустим, общая доступная в сети нагрузка для приложений равна 1 МЛН. DApp из примера ранее имеет 0,01% согласно имеющейся СГ - максимальная нагрузка 10.
Если приложение превышает нагрузку, например, на 5 единиц - 15, то батарейка уменьшается на 2%, т. е. у приложения уже максимальная нагрузка 9,8, а не 10. Если же оно продолжает превышать, причём также нагрузка равна 15, уменьшается ещё на 3%, если и после этого - ещё на 4%, и так до тех пор, пока не станет батарейка равна 0%. После этого приложение сможет только купить нагрузку за токены либо пополнить свою СГ так, чтобы нагрузка стала больше, чем была во время пика.
Покупка нагрузки - это дополнительный доход для предоставляющих ресурсы.

Сроки понижения батарейки на 2, 3, 4% и т. д. могут устанавливаться делегатами, поэтому не пишу их.
Покупка нагрузки происходит на срок равный трём суткам, но также может меняться делегатами.

5. В будущем, уже после запуска полноценной сети, стоит внедрить интеграцию с IPFS.

В чём она заключается?
В возможности добавлять адреса IPFS с данными в объекты, транзакции и смартконтракты.
К примеру, можно было бы добавлять текст поста со всеми фотками в IPFS, а в main_filde (поле текста поста) добавлять лишь адрес.
Далее Клиент (точка входа), используя методы API форка EOS, что реализует интеграцию с IPFS, конвертирует IPFS адрес в данные, например, текст поста, и отдаёт пользователю.
При этом, можно создать целую экономику:
Клиент может выбрать, какую Ноду IPFS использовать: свою или заказать получение доступа к существующей Ноде.
Предложения получить доступ к Ноде могут предлагать в сети форка через специальное децентрализованное приложение.

На этом всё.

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