Аккаунты и разрешения

Аккаунт - это учётная запись участника или группы участников ДАО VIZ, с помощью которой совершаются операции в блокчейне VIZ.

При создании аккаунта в качестве идентификатора ему присваивается выбранное участником уникальное имя длиной от 2 до 25 символов латинского алфавита. Двухсимвольные аккаунты зарезервированы за самыми первыми участниками VIZ и больше не присваиваются. Изменить имя аккаунта после создания невозможно.

Владельцы аккаунтов могут создавать аккаунты «второго уровня», а те, в свою очередь - третьего и т.д., которые отделяются от основного аккаунта (и последующих) точкой. Например, аккаунт @name (и только он) может создать аккаунт @subname.name, тот, в свою очередь, @subsubname.subname.name и т.д.

Аккаунт имеет четыре пары ключей (публичный и приватный):

  • главный ключ,
  • активный ключ,
  • регулярный ключ,
  • коммуникативный ключ.

Каждый публичный ключ должен быть создан из разных приватных ключей с использованием алгоритма на базе эллиптической криптографии для кривой secp256k1 (такая же кривая используется в Bitcoin).

Ниже в таблице приведены параметры для secp256k1

Парам етр Значение
p 0xffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f
a 0
b 7
Gx 0x79be667e f9dcbbac 55a06295 ce870b07 029bfcdb 2dce28d9 59f2815b 16f81798
Gy 0x483ada77 26a3c465 5da4fbfc 0e1108a8 fd17b448 a6855419 9c47d08f fb10d4b8
n 0xffffffff ffffffff ffffffff fffffffe baaedce6 af48a03b bfd25e8c d0364141
h 1

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

Ниже в таблице описаны все ключи и операции, которые можно совершать с их помощью

Ключ Разрешения
Регулярный Отправка `custom-транзакций <./glossary.html#custom-transaction >`__, награждение пользователей, изменение метаданных аккаунта, любые действия с комитетом.
Активный Всё, что можно делать с помощью регулярного ключа, а также операции с активами и голосование за делегатов.
Главный Всё, что можно делать с помощью регулярного и активного ключей, а также замена всех ключей.
Коммуникати вный Не позволяет подписывать транзакции, но с его помощью можно засекречивать сообщения, например, шифровать при помощи алгоритма ECDH заметки при переводе токенов.

Аккаунт с несколькими пользователями

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

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

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

Стоит учитывать, что пользователь, который получил дополнительный ключ, или аккаунт, которому приписана одна из трех ролей, при подписи транзакций от имени главного аккаунта ограничены только уровнем доступа ключа или роли. То есть, если пользователю выделен главный ключ или если аккаунту приписана главная роль, то и пользователь, и аккаунт смогут сами определять уровни доступа к главному аккаунту для других участников ДАО VIZ, и даже ограничить доступ первоначальному владельцу аккаунта.

Мультиподпись

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

Примеры мультиподписи

Пусть в аккаунте с весовым порогом 100 прописано три пользователя: Алиса, Макс и Боб. У Боба вес 25, у Макса также 25, а у Алисы - 50. Тогда Бобу для отправки транзакции нужны ещё подписи Алисы и Макса, ведь только в этом случае суммарный вес подписавшихся будет равен весовому порогу аккаунта 100. Аналогично нужно поступить Максу или Алисе, чтобы отправить транзакцию от имени аккаунта. Таким образом, никто не сможет отправить транзакцию без согласия всех участников, что позволяет избежать злоупотребления полномочиями со стороны любого из пользователей.

Если при том же распределении весов участников мультиподписи весовой порог установлен на уровне 75, то для проведения транзакции достаточно подписи Алисы (вес 50) и любого из других участников мультиподписи (с весом 25). При этом Макс (25) и Боб (25) без участия Алисы (50) подписать транзакцию не смогут.

Регистрация

Чтобы создать новый аккаунт в VIZ, необходимо отправить специальную транзакцию (account_create), которая зарегистрирует новую учетную запись. В этой транзакции указываются:

  • имя нового аккаунта (name);
  • имя аккаунта-рефера (referrer) - опционально;
  • метаданные аккаунта (json_metadata) - опционально;
  • четыре публичных ключа: главный (master_authority), активный (active_authority), регулярный (regular_authority), коммуникативный (memo).

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

Отправитель транзакции должен заплатить за создание аккаунта сумму не меньшую, чем указали делегаты. Все ликвидные токены, которые заплатит регистратор, будут конвертированы в shares нового аккаунта.

Кроме прямого перевода ликвидных токенов, есть ещё два способа создания аккаунта: регистрация через делегирование доли и создание через инвайт-код.

Регистрация через делегирование доли

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

Стоимость всех делегированных shares в viz должна быть не меньше, чем указали делегаты.

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

Если количества переведённых viz будет достаточно для регистрации за ликвидные токены, то аккаунт будет создан за viz, если не будет достаточно, то за делегированные shares. Если количества делегированных shares также будет недостаточно, то аккаунт не будет создан.

Отозвать делегированные токены регистратор сможет по умолчанию через 28 дней или через другой срок, который укажут делегаты.

Если регистратор попробует отозвать shares раньше указанного срока, то они спишутся со счета нового аккаунта, но будут заморожены до тех пор, пока не пройдёт 28 дней с момента регистрации. В случае заморозки долевыми токенами не смогут пользоваться ни регистратор, ни созданный аккаунт.

Регистрация с помощью чека на предъявителя

Подробнее про чеки читайте в разделе:Чеки на предъявителя.

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

Обладатель чека с помощью приложения или напрямую отправляет в блокчейн специальную транзакцию (invite_registration) с указанием приватного ключа чека и публичного будущего главного ключа аккаунта. Эта транзакция зарегистрирует новый аккаунт, потратив токены из чека. Все токены из чека будут конвертированы в shares нового аккаунта.

Если у человека уже есть аккаунт, то он может подписать транзакцию с помощью своей учетной записи и её приватного активного ключа. Если у него нет аккаунта, он может отправить транзакцию с помощью аккаунта @invite, который принадлежит блокчейну, подписав её приватным ключом 5KcfoRuDfkhrLCxVcE9x51J6KN9aM9fpb78tLrvvFckxVV6FyFW.

Анонимные аккаунты

Для создания анонимных аккаунтов в блокчейн был встроен специальный аккаунт @anonymous. Чтобы зарегистрировать аккаунт, надо перевести ему токены viz объемом не менее, чем указали делегаты. Вместе с переводом отправляется заметка с публичным ключом нового аккаунта. Этот ключ будет прописан как главный, активный, регулярный и коммуникативный.

Когда @anonymous получит перевод, он создаст новый аккаунт по схеме @nX.anonymous, где X — номер анонимного аккаунта. Номер @anonymous приписывает сам, каждый раз прибавляя единицу к количеству уже созданных анонимных аккаунтов.

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

Энергия

У каждого аккаунта в блокчейне есть запас энергии, который измеряется в процентах. Максимальное значение энергии равно 100%, минимальное может быть -100%, то есть меньше 0%.

Энергия нужна для того, чтобы отправлять награды другим пользователям. Если энергии не хватает, то аккаунт не сможет наградить участника необходимой суммой токенов, а если энергия равна или меньше 0%, то аккаунт вообще не сможет отправить награду. Однако, он по-прежнему сможет совершать другие операции в блокчейне, например, переводить токены между аккаунтами, голосовать за делегатов и делать всё, что мог со 100% энергии. Подробнее про награды читайте в разделе Награды за деятельность.

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

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

Блокчейн рассчитывает количество энергии, которое будет затрачено, по формуле делегировано shares / эффективные shares * 100%.

Тратится энергия моментально, но восстанавливается медленно: 20% от максимума за 24 часа, 1% за 1 час 12 минут (то есть за 1 секунду восстанавливается всего 0,01% энергии).

Данные аккаунтов

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

Для начала ознакомьтесь с таблицей типов информации, которые использует блокчейн:
Тип Пример Диапазон Описание
VIZ акти в “1.000 VIZ” от 0.001 VIZ Количество ликвидных токенов <./economy.html#viz-token> __. Строка с десятичным числом с не более чем 3 цифрами после точки и обязательной припиской VIZ через пробел. Пример: “1.123 VIZ”
SHAR ES акти в “1.000000 SHARES” от 0.000001 SHARES Количество долевых токенов. Строка с десятичным числом с не более чем 6 цифрами после точки и обязательной припиской SHARES через пробел. Пример: “1.123456 SHARES”
µSha res 1000000 от 1 Количество микродолевых токенов. 1 = 0.000001 SHARES; 1000000 = 1.000000 SHARES. Целое число.
Проц ент 1000 от 0 до 10000 Процент в целом числовом формате. 0.01% = 1; 1% = 100; 100% = 10000;
Цело е 1   Целое число. Слишком большие числа могут быть представлены строковым типом.
Байт 1   Количество байт в целом числовом формате. Слишком большие значения записаны в виде строк.
мкБа йт     Количество микробайт в целом числовом формате. Слишком большие значения записаны в виде строк. 1 Байт = 1000000 мкБайт
Врем я “2018-09-3 0T05:58:57 ”   Строковой тип времени в формате “YYYY-MM-DDThh:mm:ss”.
JSON “{”param1“ :”value“}”   Строка в формате JSON
Акка унт “example”   Имя аккаунта в строковом формате.
Ключ “VIZ8XwKjA kG5….”   Публичный ключ в строковом формате с приставкой “VIZ”.

average_bandwidth

Добавлено: 1.0.0

Формат: мкБайт

Значение скользящей средней для затраченной пропускной способности на момент последней транзакции.

lifetime_bandwidth

Добавлено: 1.0.0

Формат: мкБайт

Количество мкБайт, которое аккаунт использовал за всё время с момента создания.

balance

Добавлено: 1.0.0

Формат: VIZ актив

Количество viz на балансе аккаунта.

vesting_shares

Добавлено: 1.0.0

Формат: SHARES актив

Количество чистых Shares аккаунта.

delegated_vesting_shares

Добавлено: 1.0.0

Формат: SHARES актив

Количество Shares, которое аккаунт делегировал другим пользователям.

received_vesting_shares

Добавлено: 1.0.0

Формат: SHARES актив

Количество Shares, полученных путем делегирования.

next_vesting_withdrawal

Добавлено: 1.0.0

Формат: Время

Время, когда произойдёт следующие списание на vesting_withdraw_rate при включённом понижении доли.

to_withdraw

Добавлено: 1.0.0

Формат: µShares

Количество Shares, которое аккаунт запросил для понижения доли.

withdraw_routes

Добавлено: 1.0.0

Формат: µShares

Количество аккаунтов, с которыми аккаунт может поделить Shares во время понижения доли. Максимальное количество - 10.

vesting_withdraw_rate

Добавлено: 1.0.0

Формат: SHARES актив

Количество Shares, которое будет списываться каждый день при включённом понижении доли.

benefactor_awards

Добавлено: 2.0.0

Формат: µShares

Количество µShares(мкShares), которое аккаунт получил в качестве бенефициарских выплат с наград за всё время.

receiver_awards

Добавлено: 2.0.0

Формат: µShares

Количество µShares (мкShares), которое аккаунт получил в качестве наград за всё время.

vote_count

Добавлено: 1.0.0

Формат: Целое

Количество наград, которое отправил аккаунт. До 4 хардфорка этот параметр показывал количество голосов, которое аккаунт поставил разным постам.

created

Добавлено: 1.0.0

Формат: Время

Время, когда был создан аккаунт.

custom_sequence

Добавлено: 2.0.0

Формат: Число

Количество custom-транзакций, которое отправил пользователь с момента 4 хардфорка.

custom_sequence_block_num

Добавлено: 2.0.0

Формат: Число

Номер последнего блока, в который была помещена последняя custom-транзакция аккаунта.

energy

Добавлено: 1.0.0

Формат: Процент

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

id

Добавлено: 1.0.0

Формат: Целое

Цифровой уникальный идентификатор пользователя в системе.

name

Добавлено: 1.0.0

Формат: Аккаунт

Имя аккаунта.

json_metadata

Добавлено: 1.0.0

Формат: JSON

Метаданные аккаунта в формате JSON. В них можно, например, хранить информацию о профиле пользователя: имя, фамилия, сайт, социальные сети, пол, должность, место работы. У аккаунта @anonymous вместо JSON строки хранится количество анонимных аккаунтов. Параметр также может быть пустой строкой.

last_account_recovery

Добавлено: 1.0.0

Формат: Время

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

recovery_account

Добавлено: 1.0.0

Формат: Строка

Имя аккаунта, который может восстановить учетную запись пользователя. Если поле пусто, то доступ к аккаунту не сможет восстановить никто.

referrer

Добавлено: 1.0.0

Формат: Аккаунт

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

last_account_update

Добавлено: 1.0.0

Формат: Время

Время, когда аккаунт в последний раз обновлял ключи, роли или json_metadata.

last_owner_update

Добавлено: 1.0.0

Формат: Время

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

last_owner_update

Добавлено: 1.0.0

Формат: Время

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

witness_votes

Добавлено: 1.0.0

Формат: Массив аккаунтов

Список делегатов, за которых проголосовал пользователь.

witnesses_voted_for

Добавлено: 1.0.0

Формат: µShares

Количество делегатов, за которое проголосовал аккаунт.

witnesses_vote_weight

Добавлено: 2.0.0

Формат: µShares

Количество голосов, которое отдал пользователь за каждого делегата. Рассчитывается по формуле: (чистые s=Shares + Shares прокси-аккаунта) / witnesses_voted_for.

proxied_vsf_votes

Добавлено: 1.0.0

Формат: Массив µShares из 4 элементов

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

proxy

Добавлено: 1.0.0

Формат: Аккаунт

Имя прокси-аккаунта, которому пользователь доверил свои голоса за делегатов.

master_authority

Добавлено: 1.0.0

Формат: Массив

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

Содержит в себе account_auths и key_auths.

active_authority

Добавлено: 1.0.0

Формат: Массив

Массив, содержащий массив активных ключей и массив аккаунтов, привязанных к активной роли.

Содержит в себе account_auths и key_auths.

regular_authority

Добавлено: 1.0.0

Формат: Массив

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

Содержит в себе account_auths и key_auths.


account_auths и key_auths входят в состав параметров *_authority.

account_auths

Добавлено: 1.0.0

Формат: Массив массивов аккаунтов и их весов.

Список аккаунтов, привязанных к роли, и их весов.

Пример: account_auths: [[‘example’, 20], [‘owner’, 50]]

key_auths

Добавлено: 1.0.0

Формат: Массив массивов ключей и их весов.

Список ключей и их весов.

Пример: key_auths: [[‘VIZ6cMf37KNdYiqXNfaCf7VFQDuPUWE6z5dw9LYLbSSGg5kAN1RMi’, 20], [‘VIZ6cMf38KNeYiqXNfsCf7VFQDuPUUE6z5dw9LYLbSSGg6kAN1RMi’, 50]]


memo_key

Добавлено: 1.0.0

Формат: Ключ

Коммуникативный ключ аккаунта

awarded_rshares

Устарело: 2.0.0

Добавлено: 1.0.0

Формат: µShares

Количество rShares, которое могло участвовать в пуле конкуренции без затраты энергии вплоть до 4 хардфорка. Устарело из-за смены экономической модели - отказ от позиционирования как блог-платформа.

curation_rewards

Устарело: 2.0.0

Добавлено: 1.0.0

Формат: µShares

Количество µShares(мкShares), которое аккаунт получил в качестве бенефициарских выплат с курируемых постов до 4 хардфорка. Устарело из-за смены экономической модели - отказ от позиционирования как блог-платформа.

posting_rewards

Устарело: 2.0.0

Добавлено: 1.0.0

Формат: µShares

Количество µShares(мкShares), которое аккаунт получил за свои посты вплоть до 4 хардфорка. Устарело из-за смены экономической модели - отказ от позиционирования как блог-платформа.

last_post

Устарело: 2.0.0

Добавлено: 1.0.0

Формат: Время

Время, когда был отправлен последний пост или комментарий. Устарело из-за смены экономической модели - отказ от позиционирования как блог-платформа.

last_root_post

Устарело: 2.0.0

Добавлено: 1.0.0

Формат: Время

Время, когда был отправлен последний пост. Устарело из-за смены экономической модели - отказ от позиционирования как блог-платформа.

last_vote_time

Устарело: 2.0.0

Добавлено: 1.0.0

Формат: Время

Время голосования за последний пост. Устарело из-за смены экономической модели - отказ от позиционирования как блог-платформа.

content_count

Устарело: 2.0.0

Добавлено: 1.0.0

Формат: Целое

Количество постов пользователя. Устарело из-за смены экономической модели - отказ от позиционирования как блог-платформа.

subcontent_count

Устарело: 2.0.0

Добавлено: 1.0.0

Формат: Целое

Количество комментариев пользователя. Устарело из-за смены экономической модели - отказ от позиционирования как блог-платформы.