За замовчуванням лише ключ користувача підписує транзакції в Прозорій Мережі Stellar.
Default flow with a single signer
Як варіант, з метою зниження ризику таємної підробки транзакція також може бути підписана кількома учасниками.
Цей потік поєднує підписи з двох сторін (Контрагента та DCM):
Relations between private keys and secrets
Ключові принципи
Контрагент з самого початку вирішує, який підхід використовувати (мультипідпис або використовувати за замовчуванням з єдиним підписом)
Контрагент генерує 2 пари ключів і надає публічні частини в DCM перед ініціюванням операції
Для публікації транзакції потрібні 3 підписи (Контрагент, DCM і Клієнт)
Початкове значення Клієнта зашифровано на стороні DCM
Секрет (зберігається Контрагентом) потрібен для розшифровки початкового коду Клієнта
Контрагент використовує власне початкове значення для підписання транзакції.
Підтвердити оплату мультипідписом
На кроках 4, 5 і 9 усі три підписи додаються до конверта транзакції.
Confirm a payment
POST /sign
Приклад запиту
Аутентифікація не використовується
Адреса атрибута містить список усіх очікуваних підписантів для платежу. Конверт із tranasction_xdr для цілей тестування можна розшифрувати вручну за допомогою Stellar.Laboratory.
400 Bad request: якщо конверт має неправильну форму
трансфер припинено
401 Unauthorized: жодна з адрес з запиту недоступна для підпису
трансфер припинено
404 Not found: у випадку, якщо відповідь від GET /payments не повертає результатів.
повторна спроба буде надіслана пізніше до POST /sign (до 5 повторів)
Створення Клієнта з мультипідписом
Щоб обліковий запис клієнта мав 3 підписантів, процес створення Клієнта змінюється кроком 9, коли попередньо налаштований набір відкритих ключів приписується адресі Stellar як підписантом.
Що стосується інтеграції з API, створення відбувається як зазвичай.