Разработка приложений

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

Настройка клиента

• Сохранить конфигурацию клиента за пределами исходного кода приложения. Загрузить цепочку ID, Torii URL, подписывающую учетную запись и настройки транзакций из специальной настройки для окружающей среды.
• Сохраняйте файлы client.toml отдельно для локальной сети, Taira, Minamoto и частных сетей. Копированный подписитель тестирования никогда не должен становиться подписителем основного сети.
• Очень короткая продолжительность жизни может истечь при нормальном напряжении сети, в то время как очень длинная продолжительность может сделать дублированные представления более трудными для рассуждения.
• Используйте nonce = true только тогда, когда повторяющиеся транзакции должны иметь различные хэши. Для бессильных бизнес-операций хранить и повторно использовать запрос заявки ID, чтобы повторные попытки были отслеживаемыми.

См. Клиентная конфигурация для текущих полей TOML.

Транзакции

• По возможности создавать транзакции с помощью напечатанных инструкций SDK вместо сырых JSON или полезных нагрузок, собранных по строкам.
• Preflight important пишет с запросами только для чтения: существование учетной записи, балансы активов, состояние разрешений, доступность платежных активов и состояние целевого объекта.
• Зарегистрируйте хэш транзакции, авторитетную учетную запись, краткое описание инструкций и ожидаемое изменение состояния перед отправкой.
• Rejected, Expired, и результаты отсрочки различаются. Время отключения означает, что клиент не соблюдал окончательный статус; это не доказывает, что сеть проигнорировала транзакцию.
• После успешной записи проверьте полученное состояние с помощью контрольного пункта запроса или события, соответствующего бизнес-операции.

Для механики транзакций см. Транзакции.

Вопросы и события

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

См. Вопросы, События и Филтры .

Развитие с помощью агентов

• Позволь агентам проверить документы, код SDK, и состояние сети для чтения только перед тем как попросить их написать код транзакции.
• Поддерживайте тесты в живой сети, чтобы отказаться от использования за флагом окружающей среды, например TAIRA_LIVE=1.
• Не вставляйте частные ключи, материалы для восстановления счетов, токены API или пересылаемые заголовки авторов в запросы.
• Требуйте план транзакции, прежде чем какой-либо агент будет представлять транзакцию в тестовой сети. План должен назвать сеть, авторитет, инструкции, актив сбора, предлетные чтения, ожидаемый результат и поведение повторной попытки.

Для Taira MCP рабочий процесс, см. Настраивайся SORA 3: Taira и Minamoto.

SDK Гигиена

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