HF18: Новые возможности
1. Делегирование Силы Голоса
1.1. Операция делегирования Силы Голоса
На балансе кошельке пользователя могут храниться три вида криптовалюты — Голос, Сила Голоса и Золотой. Пользователь может за Голос приобрести Силу Голоса, что позволит ему более эффективно проводить голосование за интересующие посты. В зависимости от наличия на балансе кошелька количества Силы Голоса на момент голосования за какой-либо пост определяется размер бонуса по завершению процесса голосования. То есть размер бонуса, получаемого по результатам голосования за пост, пропорционален количеству Силы Голоса на балансе кошелька на момент голосования.
Пользователь (кредитор) может неиспользуемую часть Силы Голоса кредитовать на время (делегировать) другому пользователю, который также может ее использовать по своему усмотрению. Кредитор Силы Голоса при этом получает дополнительную возможность голосования за пост и, следовательно, возможность получения дополнительного бонуса.
Для выполнения операции делегирования кредитору Силы Голоса необходимо сформировать массив значений — блок делегирования с указанием типа операции, отправителя, получателя, сумма делегирования и пр.
Минимально возможное количество криптовалюты, необходимое для делегирования, является плавающей величиной и зависит от результатов голосования делегатов.
В блокчейне реализована блокировка различного рода злоупотреблений, связанных с использованием переводов криптовалюты из одного ее вида в другой и перечислением ее со счета на счет с целью обогащения.
1.2. Изменение или возврат делегированной Силы Голоса
Кредитор Силы Голоса в случае каких-либо обстоятельств может изменить количество делегированного как в сторону его увеличения, так и уменьшения, а также осуществить возврат делегированного в полном объеме.
Для выполнения этой операции в сформированном блоке делегирования необходимо задать новое значение количества делегированной Силы Голоса. В случае полного ее возврата следует задать значение вида “0.000000 GESTS”. При изменении значения в сторону уменьшения делегированная Сила Голоса сразу снимается с аккаунта-получателя и переходит в «замороженное» состояние сроком на 7 дней.
Для выполнения этой операции требуется авторизация с помощью ключа active.
1.3. Создание аккаунта с делегированной Силой Голоса
Пользователь может создать новый аккаунт, на балансе кошелька которого будет находиться Сила Голоса. За создание аккаунта в качестве комиссионных отчислений с баланса кошелька автора снимается определенная сумма. Величина этих отчислений не может быть меньше значения параметра fee, устанавливаемого по результатам голосования делегатов. Параметр fee показывает изначальный базовый баланс кошелька аккаунта, необходимый для его существования в системе.
Для того, чтобы пользователь нового аккаунта мог создавать посты, комментарии, а также участвовать в голосовании, необходимо, чтобы на балансе кошелька нового аккаунта появилась криптовалюта Сила Голоса в количестве не менее базового значения fee. Для этого с баланса кошелька создателя аккаунта снимается криптовалюта в виде Голоса и зачисляется на баланс кошелька нового аккаунта в виде Силы Голоса.
Вводится параметр bandwidth, устанавливающий пропускную способность аккаунта — количество операций, выполняемых пользователем за определенный период времени. Этот параметр зависит только от баланса Силы Голоса. Наличие в кошельке других видов криптовалюты (Голоса и Золотого) не оказывает на него влияния. Этот параметр ограничивает активность пользователя и не позволяет ему слишком часто создавать комментарии, принимать участие в голосовании или выполнять какие-либо другие операции.
Для операции создания аккаунта с делегированием необходима подпись ключом active. Созданный аккаунт может иметь ключи owner, active, posting и memo.
Примечания: 1. Затрачиваемое на создание аккаунта количество криптовалюты не может быть возвращено обратно в кошелек создателя.
Создатель аккаунта может делегировать часть Силы Голоса на новый аккаунт. В этом случае делегированная часть будет также списана с баланса Силы Голоса его кошелька и зачислена на баланс Силы Голоса нового аккаунта. Делегированная Сила Голоса может быть возвращена в кошелек создателя через определенный период, длительность которого определяется голосованием.
2. Предотвращение злоупотреблений делегированием Силы Голоса с целью обогащения
Для предотвращения злоупотреблений делегированием Силы Голоса, связанных с быстрыми перечислениями криптовалюты с баланса кошелька кредитора на баланс кошелька заемщика и конвертацией Силы Голоса в Голос, в блокчейне реализовано решение, предотвращающее такие действия. Решение основано на задержке операции конвертации Силы Голоса в Голос.
Обналичивание Голоса в Силу Голоса осуществляется без задержки и, напротив, обналичивание Силы Голоса в Голос осуществляется по истечении семи дней.
В случае аннулирования кредитором делегированной Силы Голоса, она немедленно будет снята с кошелька заемщика в полном объеме, но возвращена в кошелек кредитора также по истечении семи дней.
3. Улучшение способа определения биржевого курса и соотношения криптовалют
Криптовалюты Голос и Золотой могут выставляться на биржевых торгах. В экономической составляющей блокчейна реализован динамический параметр, показывающий соотношение этих двух видов криптовалют, то есть их биржевой курс. Значение этого соотношения определяется делегатами системы. Каждый из них публикует свое значение курса, которое на его взгляд считается наиболее валидным. Значения курсов сохраняются в базе данных блокчейна, где они сортируются в порядке убывания. За результирующее значение курса криптовалют принимается их медианное значение.
В предыдущих версиях в процессе определения результирующего значение курса криптовалют использовались как новые предложенные данные от делегатов, так и старые, хранящиеся в базе данных блокчейна. Наличие последних в определении курса вносило неточность в итоговый результат.
В версии HF•18 старые значения курса удаляются из базы данных блокчейна и не участвуют в определении текущего курса криптовалют. Данная реализация обеспечивает более правильную ценовую политику Голоса и Золотого на биржевых торгах.
4. Редактирование профиля пользователя с использованием ключа posting
В предыдущих версиях блокчейна редактирование любого поля профиля пользователя возможно было только с использованием ключа active. Поскольку этот ключ предназначен для выполнения наиболее ответственных операций, его использование для редактирования часто используемых полей профиля не всегда было приемлемым.
Для устранения этого недостатка в версии HF•18 принято решение разделить поля профиля на две группы. В состав первой группы вошли поля с наиболее значимыми данными профиля (ключи: posting, active, owner и memo), а в другую — с менее значимыми, но часто используемыми (аватар, пол, местонахождение и пр.). Процедура изменения полей первой группы сохранена и возможна только с использованием ключа active. Процедура редактирования полей второй группы изменена и возможна с использованием ключа posting, что является наиболее приемлемым для пользователя.
5. Предложение на транзакцию, состоящей из нескольких операций
5.1. Предложение на транзакцию
Пользователю предоставляется возможность предлагать транзакцию на блокчейне, в состав которой входят несколько отдельных операций, на выполнение каждой из которых требуется одобрение от других пользователей.
Предложение на транзакцию создается в виде блока, в который автор транзакции вводит информацию, необходимую для ее проведения. Этот блок отправляется в блокчейн, после чего пользователи видят информацию о предложенной транзакции в своих кошельках. Каждая операция из транзакции закрепляется за конкретным пользователем — участником транзакции, который может либо дать согласие на ее выполнение, либо отказаться, подписавшись соответствующим ключом.
Все подписи от участников транзакции отправляются на сервер и, в случае получения необходимого количества подписей, предложенная транзакция выполняется. На получение подписей, а также на выполнение транзакции отводится определенное время.
Право проставления подписи на выполнение любой из операций транзакции имеет каждый из участников транзакции. Например, операция публикации поста может быть назначена одному участнику транзакции, а операция перечисления вознаграждения за нее — другому. В случае несогласия другого участника с выполнением второй операции он может удалить уже поставившую подпись на выполнение первой операции данной транзакции.
Отдельная операция из перечня транзакции может рассматриваться как комплексная и на ее выполнение может быть также предложена отдельная транзакция, содержащая более одной операции. В этом случае формируется комплексная транзакция. Количество уровней вложенности комплексной транзакции ограничено и не может быть более двух. Такое ограничение вводится с целью снижения нагрузки на серверы и, соответственно, уменьшения времени выполнения транзакции.
5.2. Обновление предложенной транзакции
Автору, а также участникам транзакции, предоставляется возможность менять свое решение и обновлять уже проставленные подписи до истечения времени, отводимого на транзакцию.
Время на принятие решения участников транзакции ограничено и не может превышать максимально отведенное время на выполнение транзакции. Если транзакция не получает одобрения на выполнение какой-либо из операций, эта транзакция не отменяется и ее актуальность будет сохраняться до отведенного на ее выполнение времени. Как только все необходимые подписи будут получены, транзакция незамедлительно будет выполняться и, независимо от дальнейших решений участников транзакции, все последующие обновления будут считаться недействительными.
5.3. Удаление предложенной транзакции
В случае отказа кого-либо из участников транзакции на выполнение операции он может сформировать на блокчейне запрос на удаление предложенной транзакции. Удалить предложенную транзакцию может как ее автор, так и любой ее участник, имеющий право на подпись. Если хотя бы один из участников транзакции формирует запрос на ее удаление, то, независимо от подписей остальных участников, данная транзакция будет удалена.
5.4. Эффективность предложенной транзакции
Независимо от того, содержит ли транзакция одну операцию или несколько, для ее выполнения требуется получение необходимого количества голосов. На выполнение нескольких операций можно последовательно сформировать столько же простых транзакций. Суммарное время сбора подписей на выполнение всех транзакций будет состоять из отдельных последовательных периодов.
Предложение на транзакцию с несколькими операциями является более эффективным ввиду того, что участники транзакции одновременно получают уведомления на разрешение выполнения всех операций. В этом случае на сбор подписей отводится всего один период, а не цепочка из отдельных последовательных периодов.
6. Редактирование постов и комментариев к ним независимо от времени их публикации
В предыдущих версиях блокчейна на редактирование постов и комментариев к ним отводился определенный период, по истечении которого внесение изменений в них было невозможным. По этой причине посты со временем могли терять свою актуальность и их авторам вместо их обновления приходилось дополнительно создавать аналогичные посты в соответствии с текущей ситуацией.
В версии HF•18 этот недостаток устранен. Ограничение на выделенное для редактирования время не действует и, следовательно, в комментарии и посты всегда можно вносить свежую информацию и содержать их в актуальном состоянии.
7. Расширение перечня параметров блокчейна, значения которых определяются голосованием
Предыдущие версии блокчейна обеспечивали поддержку операции witness_update, с помощью которой определялись значения некоторых параметров делегатами Голоса по результатам голосования. В этот перечень входили следующие параметры:
1. account_creation_fee — размер комиссионных отчислений, требуемых на создание аккаунта без делегирования;
2. maximum_block_size — максимальный размер блока блокчейна;
3. sbd_interest_rate — процент, начисляемый на SBD.
Недостаток заключался в том, что использование операции witness_update не позволяло расширить перечень таких параметров.
В версии HF•18 реализована новая операция chain_properties_update, которая поддерживает более расширенный перечень параметров, значения которых определяются голосованием делегатов Голоса, и позволяет наращивать его в будущем. В новый перечень входят следующие параметры:
1. account_creation_fee — размер комиссионных отчислений, требуемых на создание аккаунта без делегирования;
2. maximum_block_size — максимальный размер блока блокчейна;
3. sbd_interest_rate — процент, начисляемый на SBD;
4. create_account_min_golos_fee — минимальный размер комиссионных отчислений в криптовалюте Голос, требуемых на создание аккаунта с делегированием;
5. create_account_min_delegation — устанавливает минимально возможное количество Силы Голоса при создании аккаунта с делегированием;
6. min_delegation — устанавливает минимально возможное количество Силы Голоса для делегирования на аккаунт;
7. create_account_delegation_time — устанавливает минимально возможное время «заморозки» (в секундах) делегированной Силы Голоса при создании аккаунта с делегированием.
Параметры устанавливаются голосованием в абсолютных значениях. Изначально каждый из параметров принимает установленное для него значение по умолчанию.
Для выполнения этой операции требуется подпись ключом active.
8. Повышение быстродействия системы за счет размещения в разных объектах полей с часто и редко используемыми данными
Каждый создаваемый пользователем пост и комментарии к нему размещаются в отдельном блоке памяти. Физически такие блоки хранятся на дисках распределенной системы.
В структуре каждого объекта, помимо поста и комментариев, содержатся метаданные и служебная информация, в том числе счетчики, используемые для расчета вознаграждения за пост. Поступление каждого голоса за пост вызывает изменение показаний счетчиков — количество набранных голосов, вес поста, а также размер ожидаемого вознаграждения на момент поступления голоса. Обработка голоса относится к наиболее часто выполняемой операции, требующей обновление объекта. Независимо от того, подлежит ли обновлению объект полностью или только в части показаний счетчиков, он требует полного перемещения с дискового пространства в оперативную память, а также последующего сохранения его на диск.
В случае обработки большого объекта, когда его объем превышает объем выделенной оперативной памяти, происходит поэтапное считывание (загрузка в память) отдельных частей объекта, требующее дополнительных системных ресурсов. По этой причине на обработку объектов большого объема затрачивается значительно больше времени в отличие от времени обработки небольших объектов, полностью размещаемых в оперативной памяти. Интенсивное голосование за пост вызывает частое перемещение объекта, в котором этот пост размещен, и, следовательно, снижение производительности системы.
С целью уменьшения времени, затрачиваемого на считывание объекта в память и сохранение его на диск, в HF•18 принято решение, разделить объект на две части, в одной из которых размещаются редко изменяемые данные объекта (метаданные и тело поста), в другой — счетчики, требующие обновления показателей с поступлением каждого голоса. Такая структура объекта позволила во время голосования перемещать в оперативную память на обработку только его изменяемую часть, в которой находятся счетчики, без риска потери какой-либо информации. Это сократило количество операций, выполняющих непосредственно перемещение объекта между диском и оперативной памятью, и, соответственно, положительно отразилось на производительности системы.
9. Повышение производительности API протокола за счет удаления неиспользуемых полей из методов плагинов, а также за счет перераспределения методов между плагинами для более эффективного их использования
9.1. Удаление неиспользуемых полей из методов плагинов
В системе кроме основных объектов хранятся объекты, обеспечивающие выполнение редкоиспользуемых функциональностей, которые пользователями могут быть не востребованы. В этих функциональностей может быть набор функций, которые могут быть востребованы пользователем. Хранение в системе таких функциональностей является малоэффективным.
В версии HF•18 было выполнено перемещение методов между плагинами с целью высвобождения из методов части неиспользуемых полей с последующим их удалением. Это позволило снизить нагрузку на используемую память.
9.2. Размещение индексных операций по блокам и аккаунтам в отдельных плагинах
В состав индексных операций блокчейна входят в основном три вида операций, выполняемых по сформированному запросу на сервер: 1. получение списка операций, находящихся в блоках; 2. получение списка операций, находящихся в транзакциях; 3. получение списка операций, выполняемых каким-либо конкретным аккаунтом или связанных с ним.
В предыдущих версиях блокчейна для получения информации об операциях третьего вида необходимо было включить плагин account_history. Недостаток заключался в том, что метод, непосредственно выполнявший данную функциональность, размещался в другом плагине database_api. Методы, выполнявшие операции видов 1 и 2 также размещались в плагине database_api. Для вызова каждого их трех методов необходимо было включать плагин account_history, что создавало дополнительную нагрузку на сервер и на потребляемую память, и, следовательно, отрицательно влияло на быстродействие системы.
Кроме этого, возникали затруднения с настройкой сервера для включения какой-либо одной операции (например, только индексирование операции по блоку и исключение других).
В версии HF•18 принято решение переместить модули, выполняющие индексные операции, из плагина database_api в плагины в соответствии с их функциональностью.
Метод, возвращающий список операций по аккаунту, был перемещен в плагин account_history, обеспечивающий данную функциональность. Методы, используемые для индексирования операций в блоках и транзакциях были перемещены в новый плагин operation_history. Это позволило логически сконцентрировать компоненты, обеспечивающие включение индексов и самих операций, по которым могут отдельно быть получены списки операций по блокам, транзакциям или по аккаунту. Теперь для получения списка операций в блоках и транзакциях достаточно будет включить плагин operation_history. Для получения более расширенной информации по аккаунтам необходимо подключить account_history. Исключение лишних операций индексирования позволило снизить нагрузку на сервер и память и, соответственно, повысить производительность системы.
10. Использование тэгов при формировании запросов на получение необходимой информации
В предыдущих версиях блокчейна поиск интересующей пользователя информации инициировал операции индексирования. Для поиска корневого элемента (например, поста или комментария) необходимо было подключиться к плагину SocialNetwork, где также инициировался поиск по дополнительным индексам. Последнее приводило к тому, что пользователю наряду с полезной также выдавалась не представляющая ему интерес информация. Из-за наличия в выдаче большого объема ненужной информации увеличивался размер файла разделяемой памяти, что негативно отражалось на производительности системы.
В версии HF•18 методы, обеспечивающие поиск информации по индексам, размещены в двух отдельных плагинах. Часть методов, обрабатывающие теги (например, получение наиболее популярных тэгов, получение списка языков, получение используемых автором списка тэгов и др.) была перемещена из плагина SocialNetwork в отдельный плагин Tag. Дополнительные индексы для сортировки по тэгам создавались только в этом плагине.
В плагине SocialNetwork сохранились методы, обеспечивающие обращение к корневым элементам для получения, например, контента, целиком вложенного дерева, списка активных голосов и др.
Такое разделение методов позволяет пользователю формировать запрос на получение только необходимой ему информации. Чтобы избежать получения контента целиком, пользователю достаточно указать параметры, по которым идентифицируется часть контента (ограничения, набор тэгов).
Поскольку пост может содержать значительное количество (более тысячи) комментариев, пользователь может сформировать запрос на получение только выбранной (отсортированной) в соответствии с указанными в тэге признаками части комментариев.
Введен параметр vote_limit, с помощью которого пользователь может ограничить получаемый список проголосовавших. Этот параметр позволяет уменьшить размер отправляемого от сервера ответа. При этом в ответе добавляется дополнительное поле active_votes_count, информирующее об общем количестве проголосовавших без получения списка целиком.
11. Получение информации о текущем статусе разделяемой памяти
В версии HF•18 реализована возможность пользователю получать информацию о текущем статусе разделяемой памяти. Для этого пользователю достаточно сформировать запрос в блокчейн. В состав получаемой информации о текущем статусе разделяемой памяти входят следующие данные: общий объем разделяемой памяти, размер свободного и зарезервированного пространства для определенных нужд, а также список индексов, хранящихся в разделяемой памяти (название индекса, количество записей).
12. Постраничный просмотр личных сообщений пользователя
Общее количество сообщений во время голосования за пост может достигать такого значения, когда просмотр пользователем личных сообщений становится затрудненным.
Для устранения этого недостатка были модифицированы методы в плагине private_message. Данная доработка обеспечивает следующие возможности:
1. выделять интересующие пользователя личные сообщения из общего потока исходящих или входящих сообщений с указанием даты их поступления;
2. просматривать личные сообщения в режиме постраничного вывода на экран;
3. ограничить количество поступающих сообщений.
13. Улучшения в подсистеме хранения блоков цепочки
В блокчейне имеются два вида хранилищ:
1. разделяемая память, размещенная в файле shared_memory.bin и предназначенная для хранения актуальных данных состояния системы;
2. цепочка из упакованных в определенном порядке подписанных блоков, размещенных в файле block_log.
Обращения к цепочке блоков происходят редко. Обычно это происходит по точечным запросам через API-вызовы для получения тела подписанного блока, синхронизации данных между серверами и ряда других операций. Каждое обращение к файлу block_log инициирует значительное количество системных вызовов, в том числе: открытие файла, поиск необходимой позиции и считывание данных из файла. Одновременно с этими операциями может выполняться запись информации в конец файла, требующая от системы подобных действий — переоткрытие файла, поиск конечной позиции в файле и запись в файл.
В предыдущих версиях блокчейна одновременные обращения к файлу block_log как по чтению, так и по записи вызывали блокирование доступа к файлу, что негативно влияло на производительность сервера. С целью устранения такого недостатка в HF-18 была реализована новая технология, обеспечивающая одновременный доступ к файлу block_log по чтению без замедления работы сервера. Блокирование доступа к файлу block_log происходит только во время выполнения операции записи.
Last updated