Узлы, которые видят mempool, это не полный список ожидающих обработки транзакций во всей сети
Особое примечание в документации Dusk HTTP API: `mempoolTxs` возвращает локальный mempool текущего узла и сортирует транзакции по цене газа; это не всеобъемлющий взгляд на сеть и он не включает будущие транзакции с более поздним nonce, которые временно находятся в prequeue. Эта граница напрямую влияет на то, как инструменты мониторинга будут определять «исчезновение транзакции».
Если приложение запрашивает узел и не видит транзакцию, это может означать, что она ещё не распространена, что другой узел её уже получил, либо что из‑за более позднего nonce она сохранена заранее в очереди prequeue. Если сразу предлагать пользователю повторно отправить транзакцию, это может спровоцировать намерение на замену и дубли. Надёжнее сочетать данные по хэшу транзакции, отправляющему узлу, nonce аккаунта и итоговому состоянию в блоке, чтобы выдать вывод с указанием источников.
Для площадок транзакций данные mempool пока нельзя напрямую использовать как основание для оценки сетевой перегруженности или уровня комиссий. Порядок сортировки на одном узле лишь показывает его локальный набор кандидатов; в определение метрик нужно включать выборку узлов, временное окно и исключения, связанные с prequeue. Если формулировка статистического охвата неясна, тем точнее будет панель — тем легче ввести пользователей в заблуждение.
Я смотрю @Dusk в разработческой документации — больше всего мне нравится такой подход: заранее ограничивать смысл API. $DUSK #DUSKARMY. надёжный продукт с данными должен сначала сказать, чего он не видит, а затем объяснить пользователю, что именно он видит — особенно нельзя по отсутствию на одном узле делать вывод, что вся сеть отбросила транзакцию.
Особое примечание в документации Dusk HTTP API: `mempoolTxs` возвращает локальный mempool текущего узла и сортирует транзакции по цене газа; это не всеобъемлющий взгляд на сеть и он не включает будущие транзакции с более поздним nonce, которые временно находятся в prequeue. Эта граница напрямую влияет на то, как инструменты мониторинга будут определять «исчезновение транзакции».
Если приложение запрашивает узел и не видит транзакцию, это может означать, что она ещё не распространена, что другой узел её уже получил, либо что из‑за более позднего nonce она сохранена заранее в очереди prequeue. Если сразу предлагать пользователю повторно отправить транзакцию, это может спровоцировать намерение на замену и дубли. Надёжнее сочетать данные по хэшу транзакции, отправляющему узлу, nonce аккаунта и итоговому состоянию в блоке, чтобы выдать вывод с указанием источников.
Для площадок транзакций данные mempool пока нельзя напрямую использовать как основание для оценки сетевой перегруженности или уровня комиссий. Порядок сортировки на одном узле лишь показывает его локальный набор кандидатов; в определение метрик нужно включать выборку узлов, временное окно и исключения, связанные с prequeue. Если формулировка статистического охвата неясна, тем точнее будет панель — тем легче ввести пользователей в заблуждение.
Я смотрю @Dusk в разработческой документации — больше всего мне нравится такой подход: заранее ограничивать смысл API. $DUSK #DUSKARMY. надёжный продукт с данными должен сначала сказать, чего он не видит, а затем объяснить пользователю, что именно он видит — особенно нельзя по отсутствию на одном узле делать вывод, что вся сеть отбросила транзакцию.