Nonce и API-кошельки

Предыстория

Децентрализованный L1 должен предотвращать атаки повторного воспроизведения (replay). Когда пользователь подписывает транзакцию перевода USDC, получатель не может транслировать её многократно, чтобы опустошить кошелёк отправителя. Для решения этой проблемы Ethereum хранит «nonce» для каждого адреса — это число, начинающееся с 0. Каждая транзакция должна использовать ровно «nonce + 1», чтобы быть включённой.

API-кошельки

Они также называются agent wallets в документации. Мастер-аккаунт может одобрить API-кошельки для подписания от имени мастер-аккаунта или любого из суб-аккаунтов.

Обратите внимание, что API-кошельки используются только для подписания. Чтобы запросить данные аккаунта, связанные с мастер-аккаунтом или суб-аккаунтом, вы должны передать фактический адрес этого аккаунта. Распространённой ошибкой является использование agent-кошелька, что приводит к пустому результату.

Очистка (pruning) API-кошельков

API-кошельки и их связанное состояние nonce могут быть очищены в следующих случаях:

Кошелёк deregistered (отменена регистрация). Это происходит с существующим безымянным API-кошельком, когда отправляется действие ApproveAgent для регистрации нового безымянного API-кошелька. Это также происходит с существующим именованным API-кошельком, когда отправляется действие ApproveAgent с совпадающим именем.
Срок действия кошелька истекает.
Аккаунт, зарегистрировавший агента, больше не имеет средств.

Важно: для тех, кто использует API-кошельки программно, настоятельно рекомендуется не переиспользовать их адреса. После отмены регистрации агента его использованное состояние nonce может быть очищено. Генерируйте новый agent-кошелёк при будущем использовании, чтобы избежать неожиданного поведения. Например, ранее подписанные действия могут быть воспроизведены после очистки набора nonce.

Nonce в Hyperliquid

Дизайн Ethereum не подходит для ончейн-стакана заявок. Стратегия маркет-мейкинга может отправлять тысячи ордеров и отмен в секунду. Требование точного порядка включения в блокчейн сломает любую стратегию.

На Hyperliquid для каждого адреса хранятся 100 наибольших nonce. Каждая новая транзакция должна иметь nonce больше наименьшего nonce в этом наборе и также никогда ранее не использоваться. Nonce отслеживаются для каждого подписанта — это адрес пользователя, если подписано приватным ключом адреса, или адрес агента, если подписано API-кошельком.

Nonce должны находиться в пределах (T - 2 days, T + 1 day), где T — unix-временная метка в миллисекундах блока транзакции.

Следующие шаги могут помочь перенести автоматизированную стратегию с централизованной биржи:

Используйте отдельный API-кошелёк для каждого торгового процесса. Обратите внимание, что nonce хранятся для каждого подписанта (т. е. приватного ключа), поэтому отдельные суб-аккаунты, подписанные одним и тем же API-кошельком, будут разделять трекер nonce этого API-кошелька. Рекомендуется использовать отдельные API-кошельки для разных суб-аккаунтов.
В каждом торговом процессе создайте задачу, которая периодически собирает в батчи запросы ордеров и отмен каждые 0,1 секунды. Рекомендуется объединять IOC- и GTC-ордера отдельно от ALO-ордеров, поскольку батчи только из ALO-ордеров приоритизируются валидаторами.
Задачи торговой логики отправляют ордера и отмены в задачу батчинга.
Для каждого батча ордеров или отмен считывайте и инкрементируйте атомарный счётчик, обеспечивающий уникальный nonce для адреса. При необходимости атомарный счётчик можно быстро перемотать к текущим unix-миллисекундам.

Такая структура устойчива к транзакциям, приходящим не по порядку в пределах 2 секунд, чего должно быть достаточно для автоматизированной стратегии, географически близкой к API-серверу.