Такие свойства могут использоваться вместо алиасов, при этом можно не беспокоиться о наличии глобального алиаса с таким именем. Либо можно трактовать их как алиасы в пространстве имени, как субдомены: если аккаунт уже имеет шлобальный алиас "abc", и установил свойство "xyz", то значение этого свойства может рассматриваться как алиас "abc.xyz".
Установка свойств другому аккаунту может применяться сервисами для присвоения пользовательским аккаунтам метаданных, либо уровней авторизации, например, биржа может установить "verificationLevel = 3". Аккаунт-получатель свойства может удалить его, но не может изменить, или передать его, в то время как аккаунт-автор свойства всегда в будущем может как удалить, так и изменить его. Также 3-я сторона (сервис) может отвечать за проверку и одобрение пользовательских аккаунтов, и все могут просто проверить, установлено ли требуемое свойство этой 3-й стороной, и рассматривать такой аккаунт как имеющий требуемый уровень верификации.
Напомню, что в readme к версии 1.7.0 Account Properties были представлены следующим образом:
- это пары "наименование" / "значение", которые могут быть установлены на любом аккаунте (кроме Генезисного) либо владельцем аккаунта, либо другим аккаунтом. "Наименования" ограничены 32-мя символами, а "значения" - 160-ю. "Наименования" уникальны в пределах аккаунта и устанавливающего аккаунта, но не глобально. Свойства аккаунтов не могут перемещаться между аккаунтами. Установивший свойство аккаунт может заменить "значение" на другое. Аккаунт (либо установивший свойство аккаунт) может удалить свойство. Нет ограничения на количество свойств, которые может иметь аккаунт. Комиссия за установку "значения" составляет 1 NXT при длине "значения" до 32 символов, плюс по 1 NXT за каждые дополнительные 32 символа.
Свойства аккаунтов управляются вызовами setAccountProperty and deleteAccountProperty. Для запроса свойств аккаунта, или установленных аккаунтом, используется вызов getAccountProperties.