Моделирование данных

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

Домены и счета

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

См. Домены, счета и Название.

Активы и NFTs

• Используйте числовые активы для фигурирующих балансов и передаваемых объемов.
• Используйте NFTs или объекты, специфические для домена, для записей, принадлежащих исключительно.
• Избегайте кодирования состояния, несущего ценность, только в метаданных. Активы и NFTs обеспечивают события жизненного цикла, семантику передачи и проверки разрешений, которые метаданные не предоставляют.
• Определить точность, политику поставок, ответственность эмитента и орган по сжиганию/мину до того, как актив будет подвергнут воздействию приложений.

Смотрите . Активы, NFTs, и RWAs.

Метаданные

• Используйте метаданные для компактных атрибутов объектов учетной записи, таких как этикетки, интеграция IDs, флаги политики, хэши, URIs или ссылки на адрес контента.
• Сохранить ключи метаданных стабильными и документированными. Изменение имен ключей после того, как клиенты зависят от них, создает проблему миграции.
• Не храните большие документы, журналы, частные пользовательские данные или состояние приложения с высокой скоростью напрямую в метаданных.
• Когда метаданные указывают на данные вне цепочки, хранить проверяемую ссылку, такую как хэш контента, URI, SoraFS путь, явная ссылка или компактный обязательство.

См. Metadata and Ledger Storage Choices и Метаданные.

Разрешения по модели

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

См. Удостоверения и Удостоверительные токены.

Форма запроса

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