Встреча в дискорд 04.10.18. Техническая реализация bandwidth на платформе CyberWay

Добрый день!

В четверг 4 октября в 16:00 по МСК состоялась встреча на платформе Дискорд. Спасибо всем, кому удалось поприсутствовать и задать свои вопросы, а также тем, кто нашел время и прослушал запись трансляции.

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

Цель данного поста: письменно зафиксировать все ключевые моменты относительно технической реализации bandwidth, которые освещались командой Golos•Core непосредственно во время встречи; ознакомить пользователей Голоса и разработчиков со всеми нюансами и постараться закрепить понимание некоторыми примерами.

Реализация bandwidth на старой платформе ChainBase

В приложении Голос активность пользователя в сети ограничена выделяемой ему величиной bandwidth.

Значение bandwidth для каждого пользователя вычисляется, исходя из наличия Силы Голоса на его балансе. Начальная сумма на балансе появляется путем зачисления на баланс вестинга со стороны аккаунта-приложения, через которое идёт регистрация, например, Golos io.

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

Минимальное значение этой базовой суммы средств в Голосах определяется делегатами путем голосования. Для определения базовой суммы необходимо учесть текущий курс Силы Голоса к Голосу и минимальный bandwidth необходимый для совершения базовых операций. Например, есть зависимость bandwidth от размера поста, который публикует пользователь и текущей активности в сети (средний размер генерируемых блоков). Другой пример - это минимальная Сила Голоса при голосовании за посты.

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

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

Использование общих ресурсов bandwidth

В приложении Голос на платформе CyberWay, которая является форком системы EOS, алгоритм вычисления bandwidth для аккаунта изменен и не зависит от величины Силы Голоса. Значение bandwidth вычисляется отдельно для CPU, NET и для RAM, и оплачивается системными токена блокчейна, отличными от токенов приложения.

Распределенное приложение может иметь на своем балансе общий bandwidth. В связи с тем, что поведение пользователей после регистрации может варьироваться, то решалась задача систематизации использования общего bandwidth, повышения эффективности его использования.

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

Эта задача является выполнимой при введении двухподписного использования bandwidth. В прототипе создан смарт-контракт управления multisig-аккаунтом приложения. В подписанты от аккаунта со стороны приложения включены наиболее активные члены сообщества из числа избранных - состав подписантов у этого аккаунта может меняться .

Для проставления подписи от имени multisig-аккаунта приложения на использование ресурсов общего bandwidth сообществом генерируется пара private-public ключей. Public-ключ хранится в блокчейне, в то время как private-ключ сообщества хранится в защищенной части сервиса (веб-сайта). Подпись на использование ресурсов проставляется приватным ключом, а проверка выполняется публичным ключом. Подписанты multisig-аккаунта могут в любой момент поменять общий private-ключ для доступа к bandwidth в случае ненадлежащего его использования. Приватный ключ позволяет использовать bandwidth, но не позволяет сделать его ликвидным или продать (например, на какой-либо бирже).

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

При создании аккаунта нового пользователя возникает необходимость оплатить место хранения аккаунта в RAM блокчейна. Чтобы пользователь не платил за создание нового аккаунта, а приложение не создавало системные аккаунты впустую, расходуя средства, предлагается схема, когда новый аккаунт остается на балансе сообщества. В этом случае аккаунт создается с двумя парами public-private ключей. У аккаунта прописывается порог равный 2 (две приватные подписи необходимы для совершения транзакции), а у каждого ключа вес, равный 1. Один приватный ключ выдается пользователю, а второй сохраняется в защищенной части сервиса сообщества.

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

Реализация такого решения позволяет более гибко распределять ресурсы bandwidth. Например, в случае появления в системе пользователя с низкой активностью, ограничившегося регистрацией, в его пользование будет выделено минимальное количество ресурсов. В будущем делегаты сообщества смогут регулировать bandwidth (докупать его для новых пользователей в случае нехватки ресурсов и т.д.).

Важно, что у каждого пользователя в любой момент времени имеется возможность выкупить свой аккаунт у приложения и выйти из двухподписного правила для каждой транзакции, для чего требуется выкупить место для хранения своего аккаунта у сообщества за системные токены. Стоимость выкупа определяется правилами блокчейна - это то количество системных токенов, которое необходимо заплатить за RAM для хранения аккаунта с его балансами. Пользователю необходимо учесть, что для совершения транзакций ему понадобится докупить системные токены блокчейна для bandwidth, CPU и NET.

Таким образом, в Cyberway будут пользователи двух типов: пользующиеся личным bandwidth и те, которые пользуются общим bandwidth, имеющемся на балансе определенного приложения.

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