Аккаунты и разрешения¶
Аккаунт - это учётная запись участника или группы участников ДАО 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
Формат: мкБайт
Количество мкБайт, которое аккаунт использовал за всё время с момента создания.
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 хардфорка этот параметр показывал количество голосов, которое аккаунт поставил разным постам.
custom_sequence¶
Добавлено: 2.0.0
Формат: Число
Количество custom-транзакций, которое отправил пользователь с момента 4 хардфорка.
custom_sequence_block_num¶
Добавлено: 2.0.0
Формат: Число
Номер последнего блока, в который была помещена последняя custom-транзакция аккаунта.
energy¶
Добавлено: 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
Формат: Массив
Массив, содержащий массив главных ключей и массив аккаунтов, привязанных к главной роли.
active_authority¶
Добавлено: 1.0.0
Формат: Массив
Массив, содержащий массив активных ключей и массив аккаунтов, привязанных к активной роли.
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]]
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
Формат: Время
Время голосования за последний пост. Устарело из-за смены экономической модели - отказ от позиционирования как блог-платформа.