ТРАНЗАКЦИЮ В DUSK МОЖНО «ПРИНЯТЬ» ДО ТОГО, КАК ОБМЕН ДОЛЖЕН СЧИТАТЬ ЕЁ ЗА ВЫПОЛНЕННУЮ.
Я читал API транзакций у @Dusk , и один статус-код задел меня больше, чем обычно: разговоры о финальности:
202 Accepted.
Когда узел Dusk возвращает 202 после того, как транзакция была распространена, это означает, что транзакция принята для маршрутизации.
Это ещё не доказывает, что она попала в реальный mempool, дошла до пиров, успешно выполнилась или стала финальной.
Похоже на мелкую деталь API.
Но для обмена, обрабатывающего выводы, я так не думаю.
Я мысленно относился к обработке вывода почти как к:
отправить транзакцию → сеть принимает её → ждать финальности → закрыть вывод.
Но в середине есть неловкое промежуточное состояние: обмен отправил что-то, но всё ещё не имеет достаточно информации, чтобы безопасно считать экономическое действие завершённым.
Это меняет задачу.
Отправка транзакции — это не завершение транзакции.
И повторить неудачный запрос к API — это не обязательно то же самое, что решить, что исходный вывод никогда не существовал.
В документации Dusk даже говорится, что сервис подписания должен сериализовать выделение nonce, хранить отправленные транзакции и проверять ожидаемое и подтверждённое состояние аккаунта, прежде чем повторно использовать nonce.
Вот что мне здесь интересно.
Детерминированная финальность может сделать конец транзакции очень ясным.
Но она не может автоматически сделать все состояния до финальности одинаково простыми для того, чтобы обмен мог их обрабатывать.
Поэтому, если бы я оценивал серьёзную интеграцию Dusk, я бы не только измерял скорость расчётов.
Мне бы хотелось знать, что происходит во время отказов узлов, таймаутов и неоднозначных отправок:
Сколько выводов можно восстанавливать автоматически, не создавая дубликаты инструкций или не требуя, чтобы кто-то вручную решил, что произошло?
Лучшая инфраструктура транзакций — та, где путь ошибки становится скучным.
Похоже, это намного сложнее, чем сделать счастливый путь быстрым.
#dusk $DUSK @Dusk
$GPS $TUT
Я читал API транзакций у @Dusk , и один статус-код задел меня больше, чем обычно: разговоры о финальности:
202 Accepted.
Когда узел Dusk возвращает 202 после того, как транзакция была распространена, это означает, что транзакция принята для маршрутизации.
Это ещё не доказывает, что она попала в реальный mempool, дошла до пиров, успешно выполнилась или стала финальной.
Похоже на мелкую деталь API.
Но для обмена, обрабатывающего выводы, я так не думаю.
Я мысленно относился к обработке вывода почти как к:
отправить транзакцию → сеть принимает её → ждать финальности → закрыть вывод.
Но в середине есть неловкое промежуточное состояние: обмен отправил что-то, но всё ещё не имеет достаточно информации, чтобы безопасно считать экономическое действие завершённым.
Это меняет задачу.
Отправка транзакции — это не завершение транзакции.
И повторить неудачный запрос к API — это не обязательно то же самое, что решить, что исходный вывод никогда не существовал.
В документации Dusk даже говорится, что сервис подписания должен сериализовать выделение nonce, хранить отправленные транзакции и проверять ожидаемое и подтверждённое состояние аккаунта, прежде чем повторно использовать nonce.
Вот что мне здесь интересно.
Детерминированная финальность может сделать конец транзакции очень ясным.
Но она не может автоматически сделать все состояния до финальности одинаково простыми для того, чтобы обмен мог их обрабатывать.
Поэтому, если бы я оценивал серьёзную интеграцию Dusk, я бы не только измерял скорость расчётов.
Мне бы хотелось знать, что происходит во время отказов узлов, таймаутов и неоднозначных отправок:
Сколько выводов можно восстанавливать автоматически, не создавая дубликаты инструкций или не требуя, чтобы кто-то вручную решил, что произошло?
Лучшая инфраструктура транзакций — та, где путь ошибки становится скучным.
Похоже, это намного сложнее, чем сделать счастливый путь быстрым.
#dusk $DUSK @Dusk
$GPS $TUT