Основные положения CyberWay

Уважаемые делегаты и члены коммьюнити,

Предлагаем вам ознакомиться с данным документом, покрывающим основные положения платформы CyberWay на 13 декабря 2018 г.

Введение

Команда разработчиков Golos•Core представляет новую блокчейн-платформу CyberWay, созданную на базе EOS, но имеющую более гибкую возможность в предоставления сервиса пользователям разных сообществ.
Основным направлением развития CyberWay является создание децентрализованной системы с поддержкой на одном блокчейне одновременно нескольких приложений, функционирующих на основе смарт-контрактов и обеспечивающих хождение разного вида токенов.

1. Назначение блокчейн-платформы CyberWay

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

• децентрализованное управление;
• масштабируемость приложений;
• отсутствие цензурирования.

2. Полная совместимость c EOS

2.1. Структурная схема платформы CyberWay

Платформа CyberWay реализуется на форке EOS. Поверх платформы CyberWay предусматривается создание приложений, функционирующих на основе смарт-контрактов (рис.1).

Рис. 1 — Структурная схема технического решения платформы CyberWay

Подсистема бэндвич

Подсистема бэндвич контролирует выделение ресурсов CPU, NET и RAM пользователям системы и обеспечивает более эффективное их использование. В состав подсистемы входят два вида бэндвича:

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

Хранилище состояния системы

В платформу CyberWay интегрируется внешней БД с высоким быстродействием для хранения состояния системы. Интегрирование внешней БД вызвано необходимостью использовать механизмы СУБД, в том числе:

• Интерфейс гибкого доступа к данным, сохраняемым с помощью смарт-контрактов (EOS предоставляет возможность реализовать логику в виде смарт-контрактов, но не обеспечивает гибкий доступ к данным);
• Механизмы масштабирования, настроек, резервирования и другой, уже имеющийся в СУБД функционал.

Событийная модель
В состав [событийной модели] входят приложение в виде смарт-контракта (генератора событий) и компонент, формирующий очередь событий и транслирующий события на получателей событий.

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

Очередь событий
Сервисный компонент, формирующий [очередь событий] в виде готовых API-вызовов с указанием адресатов, операций и параметров.

Веб-ассемблер платформы
Платформа CyberWay реализована на программном языке С++. Поскольку смарт-контракты могут использовать другие языки программирования, взаимодействие смарт-контрактов между собой, а также их обращения к компонентам платформы осуществляются через веб-ассемблер.

2.2. Обоснование создания отдельной платформы CyberWay на основе логики EOS

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

• Высокая стоимость используемой памяти в EOS. По данным веб-сайта eosrp.io на октябрь 2018 г. стоимость памяти RAM за хранение 1 КБ данных составляло $0,533. С учетом этого, например, на хранение только данных о пользователях и консенсусных данных о постах и результатах голосования за неделю может потребоваться память объемом не менее 400 МБ, на что требуется не менее $200,000.

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

В этом случае наиболее эффективным решением является создание кэш-сервисов, чтобы считывать данные из блоков и сохранять их в БД, где они легко обрабатываются. Реализация такого решения непосредственно на платформе EOS затруднена.

• В EOS система функционирует в соответствии с принятой Конституцией (например, если какие-то пользовательские данные, хранящиеся в БД, не используются в течении 3 лет, они переходят во владение EOS). Не каждое сообщество могло бы принять действующую Конституцию EOS, что ограничило бы привлечение дополнительных пользователей и, следовательно, создание новых приложений.

• Поскольку EOS располагает значительно большими ресурсами, то чтобы избежать технологического отставания при разработке CyberWay необходимо продолжать импортировать появляющиеся в логике EOS полезные реализации. Устранив при этом слабые места (недостатки) EOS, CyberWay может занять свою нишу на рынке платформ для децентрализованных приложений.

• Платформа EOS ориентирована на создание блоков с максимально достижимой частотой — два блока в секунду. Такая высокая частота создания блоков эффективна в маркетинге, но ограничивает допустимую сложность логики смарт-контрактов, размещаемых на платформе EOS. Снизив требования по скорости, CyberWay может удовлетворить спрос разработчиков приложений, для которых наиболее важным фактором является не скорость, а надежность.

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

3. Приложения

3.1. Разделяемый бэндвич
Активность пользователя в сети ограничена выделяемой ему пропускной способностью — бэндвич (англ. bandwidth). Пользователь может проявлять свою активность в системе (создавать транзакции на публикации или голосование, например) только в том случае, если на его балансе имеются средства, выделенные (находящиеся в состоянии заблокированных - англ. stacked) на проведение транзакций в количестве не менее базового значения. Наличие средств учитываются при вычислении значения бэндвич для этого аккаунта. Значение бэндвича вычисляется отдельно для CPU, NET и RAM.

Распределенное приложение может иметь на своем балансе единый ресурс бэндвича — разделяемый бэндвич. Доля бэндвича выделяется пользователю непосредственно при выполнении им транзакции в системе, что обеспечивает динамическое распределение ресурсов бэндвича. Для проставления подписи от имени приложения (аккаунта с мультиподписью, от англ. multisig-account) на использование ресурсов бэндвич приложением создается пара личного и публичного (англ. private-public) ключей.

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

Рис. 2 — Схема подписания транзакции с использованием ресурсов разделяемого бэндвича

Реализованная в CyberWay логика подcистемы бэндвич обеспечивает распределение ресурсов разделяемого бэндвича с учетом степени активности пользователей и наличием оставшихся ресурсов. Ресурсы бэндвича выделяются только на выполнение транзакции и не могут быть выделены неактивным пользователям. В случае нехватки ресурсов недостающая их часть выкупается у системы.

3.2. Приоритетный бэндвич

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

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

Чтобы предоставить пользователям равные условия, в CyberWay планируется реализовать метод распределения ресурсов по принципу приоритетного бэндвича.

Общая полоса пропускания разделяется на две зоны:

1. зона гарантированной полосы пропускания (в классическом EOS-варианте), обеспечивающая выделение аккаунту доли ресурсов в соответствии с его количеством заблокированных токенов;
2. зона приоритетной полосы пропускания, выделяемая аккаунту в соответствии с его приоритетом.

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

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

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

Решение о том, в какой пропорции общая полоса пропускания (бэндвича) распределяется между зонами гарантированной и приоритетной полос, принимается блок-продюсерами.

3.3. Аренда памяти

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

В CyberWay аренда памяти реализована в соответствии со следующим алгоритмом:

• каждый блок-продюсер устанавливает стоимость 1 KБ памяти в месяц (медиана установленных значений - базовая цена аренды);
• пользователи отправляют заявки на аренду определенного объема памяти за определенный месяц;
• если по истечении недели после подачи заявки спрос (суммарный объем запрашиваемой в аренду памяти всех заявок) не превышает предложение (объем предоставленной блок-продюсером памяти за вычетом уже арендованной части памяти), то заявка исполняется и за пользователем резервируется нужный объем памяти по базовой цене;
• в случае возникновения недостатка памяти аренда предоставляется на основе аукциона.

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

Примечание:
В EOS было принято решение предоставлять занимаемую память как собственность заплатившему за нее аккаунта. Недостаток такого решения был в том, что издержки за занимаемую память накладывались не на ее владельца, а на блокчейн и, как следствие, на блок-продюсера. Поскольку за предоставление памяти блок-продюсеры несут постоянные издержки, с потребителей взимается повременная плата.

3.4. База данных для хранения состояния системы

Для хранения состояния системы на платформу CyberWay интегрируется внешняя БД, позволяющая использовать механизмы СУБД, в том числе:

• интерфейс гибкого доступа к данным смарт-контрактов;
• механизмы масштабирования, настройки, резервирования и другой, уже имеющийся в СУБД функционал.

На платформе CyberWay предусматривается поддержка двух видов хранилищ — MongoDB и RocksDB. В зависимости от используемого вида хранилища настройка узла (ноды) блокчейна возможна в следующих вариантах:

• нода блокчейна в варианте с MongoDB;
• нода блокчейна в варианте с RocksDB.

Нода блокчейна в варианте с MongoDB требует администрирования двух процессов — непосредственно процесса с БД и процесса с нодой блокчейна, что может вызвать неудобство в работе блок-продюсеров.

Нода блокчейна в варианте с RocksDB, в отличие от первого варианта, будет представлять собой монолитный сервис, не требующий сопровождения каких-либо дополнительных процессов, так как БД архитектурно является встроенной. Этот вариант реализации позволяет создавать менее требовательные узлы (ноды) в отношении к оперативной памяти.

Примечание:
Основываясь на данные официальных сайтов, предполагается, что узлы блокчейна в варианте с RocksDB, обеспечат большее быстродействие относительно узлов блокчейна в варианте с MongoDB.

3.5. Генератор событий на основе смарт-контракта

В блокчейне построена подсистема событийной модели, внутри которой находится приложение — смарт-контракт (генератор событий), и очереди событий, выполняющей передачу событий внешним приложениям.

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

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

4. Длинные доменные имена

При создании аккаунта ему присваивается идентификационное имя длиной 8 байтов в кодировке base32, которое представляет собой символьную строку из 12,5 символов. На 12 символов отводится 60 бит. Оставшиеся 4 бита отводятся под дополнительный символ из множества {1,2,3,4,a,b,c,d,e,f,g,h,i,j}.

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

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

В логику блокчейна добавляются две сущности:

• преобразователь доменного имени в идентификатор аккаунта;
• доменная транзакция, позволяющая выполнять операции, относящееся к смарт-контракту.

Добавление доменного имени к аккаунту позволяет формировать доменные транзакции — транзакции с привязкой к домену. В ней указывается вызываемый смарт-контракт и выполняемые им операции. Доменное имя не является идентификатором и может передаваться от одного аккаунта к другому.

5. Децентрализация

5.1. Время генерации блока

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

С увеличением децентрализации системы узлы блокчейна могут находиться в разных регионах и поэтому время передачи данных между узлами (нодами) блокчейна увеличится. Для CyberWay время генерации одного блока будет составлять 3 с.

Примечание:
Блокчейн EOS в силу своей централизации позволяет уменьшить время генерации блока до 0,5 с.

5.2. Количество блок-продюсеров

Блок-продюсер предоставляет в пользование свое личное оборудование и отвечает за безопасное функционирование узлов (нод) сети.

В обязанности блок-продюсера входят:

• развертывание и настройка своего узла (ноды) сети;
• голосование за параметры сети: пропускная способность сети, распределение бэндвича, объем доступной памяти и др.;
• следить за объемом доступной памяти, и отправлять данные пользователей в архив в случае неоплаты аренды памяти;
• создание и подписание блоков.

Блок-продюсер получает вознаграждение за каждый подписанный им блок.

С целью создания большей децентрализации системы предусматривается увеличение количества блок-продюсеров на платформе CybeWay до 101 включительно.

5.3 Алгоритм консенсуса DPoS в CyberWay

(находится на стадии проработки моделей, используемых в Cosmos, Tezos и EOC)

При регистрации кандидаты в БП указывают стартовую и максимальную комиссию, скорость с которой комиссия может быть увеличена, минимальное количество собственных застейканных токенов и т.д.
Пользователь голосует за некоторое к-во кандидатов (от 1 до M) застейканными (на cpu- и net- bandwidth) токенами. Вес голоса пользователя рассчитывается по формуле: w = S / sqrt(m), где S - количество застейканых токенов, m - количество кандидатов, за которых пользовать отдал свой голос.

[В DPOS30 w = S, в Cosmos w = S / m, предлагаемый вариант -- промежуточный. Взять без изменений вариант из Cosmos представляется ненадежным, в нем атакующий сможет относительно дешево избрать небольшое количество нужных ему БП. Для Cosmos это не является существенной проблемой т.к. там BFT при подписании блоков, наш блокчейн в этом смысле уязвимее]

Первые A кандидатов становятся активными БП, еще R -- резервными [A и R - консервативно голосуемые параметры]. Таким образом на часть эмиссии претендуют A + R избранных БП.

v% эмиссии распределяется между избранными БП; (100 - v)% -- между активными, за непосредственное производство блоков [v -- консервативный параметр]

Эмитированные на конкретного БП токены распределяются следующим образом: часть (задаваемая БП при регистрации) идет БП, остальное делится между всеми проголосовавшими за данного БП пропорционально доле токенов (вес при распределении награды на i-го проголосовавшего: q_i = S_i / m_i). Застейканные БП токены считаются его голосом за себя.

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

Процент эмиссии линейно зависит от доли застейканных токенов, и задается двумя числами: эмиссия при %0 и при 100%.

[Эти числа, наряду со штрафами и другими консервативными параметрами, можно настраивать при помощи голосования стейкхолдеров, подобного amendment rules из Tezos, для принятия изменения необходим кворум (процент постепенно подстраивается под активность голосующих) и абсолютное большинство "за"]

5.4. Отсутствие цензурирования и законов взаимодействия в коде (отсутствие у блок-продюсеров «черного» и «серого» списков пользователей)

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

Платформа CyberWay (в отличие от EOS) не содержит в своем коде какие-либо контролирующие пользователей программные компоненты, выполняющие разного рода привилегированные действия (например, исполнение роли Арбитража) и гарантирует их отсутствие в своей системе. Все пользователи имеют одинаковые возможности как в работе с смарт-контрактами, так и во взаимодействии между собой.

С целью создания большей децентрализации системы и привлечения большего количества пользователей в системе CyberWay, в отличие от EOS, отсутствуют Конституция, а также в каком-либо виде «серый» или «черный» списки аккаунтов, ограничивающие или полностью блокирующие выполнение аккаунту каких-либо операций (транзакций).

Система CyberWay оставляет пользователям возможность введения каких-либо гарантийных правил для разрешения конфликтных ситуаций между двумя сторонами с привлечением третьей стороны в качестве Арбитража (например, привлечение третьей стороны в качестве Арбитража-гаранта перед совершением какой-либо сделки между двумя сторонами. В том числе, зачисление на счет Арбитража активов одной из сторон до совершения сделки и получение гарантий на их передачу другой стороне после выполнения всех условий сделки).

Примечание:
В отличие от CyberWay, в EOS существует контролирующий действия пользователей орган, наделенный полномочиями в соответствии с принятой в системе Конституцией. Наличие такого органа в системе ограничивает ее децентрализацию. Это одна из причин отказа в построении приложений непосредственно на платформе EOS, а также принятия решения по созданию отдельной платформы CyberWay.

Контролирующим органом в EOS являются привилегированные аккаунты. В число таких аккаунтов входит EOSIO, EOSIO.PRODS, EOSIO.WRAP и ряд других. Основанием для рассмотрения претензий одного аккаунта к другому являются Рикардианские контракты. Они представляют собой текстовое описание правил функционирования смарт-контракта и реализованы в программном коде блокчейна. В них также приведены положения по разрешению конфликтных ситуаций (в случае их возникновения между пользователями) с указанием третьей стороны, выступающей в качестве Арбитража. В EOS в качестве исполнителя решений Арбитража может выступать привилегированный аккаунт.

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

5.5. Воркеры

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

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

Воркер выполняет работу по реализации предложения в соответствии с техническим заданием.

6. Заключение

Предложенное командой Golos•Core техническое решение по созданию платформы CyberWay предоставляет следующие возможности пользователям блокчейна:

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

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