Отделите юридическое соглашение от исполняемого кода
Смарт‑контракт автоматизирует формализованную часть процесса, но сам по себе не описывает все юридические условия, исключения и способы разрешения спора. Свяжите версию кода с текстом соглашения, моделью данных и утверждённым регламентом. Для каждого автоматического решения укажите, какой факт его запускает и кто отвечает за достоверность этого факта.
Начинайте с конечного автомата бизнес-объекта: создан, подтверждён, отгружен, принят, оплачен, оспорен, отменён. Явные переходы легче тестировать и сопоставлять с ERP, чем набор разрозненных функций.
Проведите границу on-chain и off-chain
В цепочке храните минимум, необходимый нескольким сторонам для общей проверки: идентификатор, состояние, хеш доказательства, подписи и время. Номенклатура, персональные сведения, сканы, расчётные модели и большие документы остаются в корпоративных системах. Их версия связывается с транзакцией стабильным идентификатором и хешем.
Такой подход снижает стоимость операций и риск раскрытия данных, но требует управлять доступностью внешнего хранилища. Архив, резервные копии и срок хранения должны обеспечивать проверку доказательства спустя годы.
Используйте интеграционный адаптер, а не прямую связь ERP с узлом
Отдельный сервис преобразует бизнес-события в команды смарт‑контракта, подписывает их разрешённым ключом, отслеживает подтверждение и передаёт результат обратно. Он же выполняет схему данных, лимиты, дедупликацию, очередь повторов и аудит.
Каждой операции присваивается идемпотентный ключ. Повтор после тайм-аута не должен создавать вторую поставку или выплату. Состояния «отправлено», «включено в блок», «достигло требуемого подтверждения» и «отклонено» различаются — ERP не должна считать операцию завершённой сразу после отправки транзакции.
Оракулы требуют собственной модели доверия
Смарт‑контракт не может самостоятельно проверить внешний API, курс, показание датчика или факт доставки. Оракул переносит этот факт в цепочку, но одновременно создаёт новую границу доверия. Определите разрешённые источники, подпись данных, допустимую давность, число подтверждений, правила агрегации и безопасное поведение при расхождении.
Для корпоративного процесса оракулом может быть не публичный сервис, а набор подписывающих организаций или защищённый шлюз. Важно, чтобы контракт проверял происхождение и свежесть значения, а оператор видел задержку и отказ канала.
Спроектируйте ключи и идентичности как отдельный сервис
Разделяйте пользовательскую идентичность, сервисную учётную запись и адрес в цепочке. Политика должна объяснять, кто имеет право инициировать операцию, кто подписывает техническую транзакцию и как бизнес-действие связывается с конкретным сотрудником. Критичные ключи размещаются в защищённом хранилище или аппаратном модуле, а не в коде интеграции.
Предусмотрите ротацию без остановки процесса, отзыв при увольнении или инциденте, многостороннее утверждение административных действий и журнал соответствия между корпоративными ролями и адресами.
Обрабатывайте реорганизации, задержки и отказ
Разные сети дают разные гарантии финальности. Интеграция должна ждать согласованное число подтверждений либо явное событие финальности, уметь пережить временное расхождение цепочки и повторно сверять состояние. Очередь сообщений хранит исходную команду, идентификатор транзакции, текущий этап и причину последней ошибки.
Если сеть или оракул недоступны, бизнес-процесс переходит в видимое состояние ожидания, а не продолжает работу по предположению. Для аварийного ручного решения нужны роль, основание, двойное подтверждение и последующая сверка.
Наблюдаемость должна соединять два мира
Единый correlation ID связывает документ ERP, сообщение интеграции, транзакцию, событие контракта и запись мониторинга. Панель показывает задержку отправки и подтверждения, размер очереди, долю ошибок, стоимость операций, устаревшие данные оракула и расхождения состояний.
Журнал не должен содержать закрытые ключи и лишние персональные данные. Однако его должно хватать, чтобы восстановить ход решения и доказать, какой код, вход и роль создали результат.
Приёмка проверяет полный контур
Испытайте нормальный путь, повтор команды, тайм-аут, недоступность узла, ошибочный оракул, смену ключа, откат ERP, обновление контракта и ручное восстановление. Сверьте отчётность всех участников после каждого сценария.
Production готов только тогда, когда бизнес видит однозначный статус, инженеры могут безопасно повторить операцию, служба ИБ управляет ключами, а спор можно разобрать по связанным доказательствам от исходного документа до транзакции.