Мультипідпис для трансферів
Last updated
Last updated
За замовчуванням лише ключ користувача підписує транзакції в Прозорій Мережі Stellar.
Як варіант, з метою зниження ризику таємної підробки транзакція також може бути підписана кількома учасниками.
Цей потік поєднує підписи з двох сторін (Контрагента та DCM):
Контрагент з самого початку вирішує, який підхід використовувати (мультипідпис або використовувати за замовчуванням з єдиним підписом)
Контрагент генерує 2 пари ключів і надає публічні частини в DCM перед ініціюванням операції
Для публікації транзакції потрібні 3 підписи (Контрагент, DCM і Клієнт)
Початкове значення Клієнта зашифровано на стороні DCM
Секрет (зберігається Контрагентом) потрібен для розшифровки початкового коду Клієнта
Контрагент використовує власне початкове значення для підписання транзакції.
На кроках 4, 5 і 9 усі три підписи додаються до конверта транзакції.
Аутентифікація не використовується
У відповіді обов'язкові обидва атрибути: адреса та підпис на конверті. У транзакції_xdr потрібен принаймні 1 підпис.
400 Bad request: якщо конверт має неправильну форму
трансфер припинено
401 Unauthorized: жодна з адрес з запиту недоступна для підпису
трансфер припинено
404 Not found: у випадку, якщо відповідь від GET /payments не повертає результатів.
повторна спроба буде надіслана пізніше до POST /sign (до 5 повторів)
Щоб обліковий запис клієнта мав 3 підписантів, процес створення Клієнта змінюється кроком 9, коли попередньо налаштований набір відкритих ключів приписується адресі Stellar як підписантом.
Що стосується інтеграції з API, створення відбувається як зазвичай.
Адреса атрибута містить список усіх очікуваних підписантів для платежу. Конверт із tranasction_xdr для цілей тестування можна розшифрувати вручну за допомогою .
Блок «manageDataOp» містить атрибут payment_guid, який слід використовувати в методі щоб отримати реквізити трансферу.