Интерактивные транзакции
Перевод Epic — это обмен, а не трансляция. Два кошелька передают друг другу документ, называемый слейтом (slate), каждый добавляет свою половину криптографии, и только после этого что-либо попадает в цепочку.
Это следует из схемы обязательств (commitment), описанной в модели MimbleWimble. Выход (output) получателя фиксирует ослепляющий фактор (blinding factor), известный только получателю, а подпись превышения (excess signature) транзакции является агрегатом, в который обе стороны должны внести вклад. Отправитель не может завершить транзакцию в одиночку.
Последовательность
Отправитель формирует частичный слейт и резервирует свои входы (inputs) локально. Слейт передаётся получателю через используемый транспорт. Получатель добавляет выход (output) и частичную подпись и возвращает слейт тем же путём. Отправитель завершает агрегатную подпись и транслирует в сеть готовую транзакцию на узел.
- Отправитель собирает частичный слейт (slate). init_send_tx выбирает входы (inputs) и записывает первый раунд. tx_lock_outputs затем резервирует эти входы локально, до того как получатель что-либо сделал.
- Слейт передаётся получателю. Файл, HTTP-запрос или сообщение в очереди релея. Транспорт — та часть, которая на практике даёт сбой.
- Получатель завершает свою половину. receive_tx добавляет выход (output), его доказательство диапазона (range proof) и частичную подпись, после чего слейт содержит двух участников.
- Слейт возвращается тем же путём. Через epicbox это приходит асинхронно, поэтому у отправителя тоже должен быть запущен слушатель.
- Отправитель финализирует и публикует. finalize_tx завершает агрегированную подпись, а post_tx транслирует её в сеть. Только теперь узел видит транзакцию.
Шаги 01 и 02 происходят внутри одного send на всех транспортах, кроме file. Резервирование на шаге
01 выполняется с момента начала отправки, а не её завершения. См. что резервирует выходы.
Инвойс-поток меняет роли местами. Получатель платежа вызывает issue_invoice_tx, чтобы запросить сумму,
плательщик вызывает process_invoice_tx, чтобы её обеспечить, и получатель платежа вызывает finalize_invoice_tx. Криптография та
же; меняется только инициатор.
Причины сбоя переводов
Сбои почти всегда происходят при доставке, а не в цепочке:
- Получатель не слушал. Отсутствие слушателя означает отсутствие второго раунда и транзакции.
- Релей не доставил слейт. При использовании epicbox слейт ожидает в очереди, пока получатель не переподключится. У этой очереди есть ограничения; см. гарантии доставки.
- Отправитель исчез между раундами. Получатель выполнил свою часть и вернул слейт, который ни один кошелёк не ожидает. В epicbox обратный путь требует собственной подписки отправителя; см. сравнение.
- Два кошелька не согласны по версии слейта. См. версии слейта.
Повторная отправка того же перевода не устраняет ни одну из этих проблем, поскольку входы отправителя уже зафиксированы в первой попытке. Отмените транзакцию и начните заново. См. что освобождает их.
Содержимое слейта
Слейт представляет собой JSON. id — это UUID, который обе стороны используют для перевода; это ваш
идентификатор незавершённой отправки, поэтому сохраняйте его. num_participants равно 2 для обычного перевода, а
participant_data содержит по одной записи на каждую сторону с её публичными нонсами и частичной подписью.
Сравнение длины participant_data с num_participants показывает, в каком раунде находится слейт. Меньшее количество записей
означает, что слейт ещё исходящий и ожидает получателя; равное — что он вернулся и может быть
финализирован.
amount и fee указаны в freemen, комиссию устанавливает отправитель. tx — это формируемая
транзакция, содержащая входы, выходы и ядра (kernels). height — высота блока цепочки, которую наблюдал
отправитель, а lock_height — высота блокировки ядра (kernel). ttl_cutoff_height — необязательная высота истечения срока;
её наступление не освобождает выходы; см. что освобождает их. payment_proof — необязательный запрос
доказательства платежа; см. доказательства платежа. version_info содержит версию формата слейта и
версию, которую отправитель хочет получить в ответ.
Типы полей и значения по умолчанию приведены в справочнике Wallet Owner API.
Версии слейта
Используются два формата: V2 и V3. V3 содержит два поля, которых нет в V2 — ttl_cutoff_height и payment_proof, — и
преобразование слейта V3 в V2 отбрасывает оба. Какие транспорты выполняют преобразование и,
следовательно, поддерживают доказательство платежа, указано в сравнении.
target_slate_version запрашивает формат. Передайте 2 или 3.