API предоставляет доступ к узлу или сервису с собственными ограничениями и зависимостями. В Ethereum запрос или симуляция состояния отличаются от публикации транзакции. Примеры относятся к Ethereum, а не ко всем блокчейнам.
Чтение и отправка имеют разные последствия
В Ethereum eth_call выполняет вызов без создания транзакции в цепочке; RPC-провайдер всё же может брать плату за сервис. eth_sendRawTransaction отправляет уже подписанную транзакцию. Полученный идентификатор не доказывает включение или успех. Проверьте квитанцию, статус, блок и подходящую для сети финальность.
Управлять зависимостями и ошибками
Перед подписью проверьте сеть, адрес, интерфейс контракта и параметры. Симуляция не гарантирует позднейший результат при изменении состояния. Выполненная с ошибкой транзакция всё равно может расходовать gas. Смарт-контракт — программа; название не гарантирует отсутствие ошибок или юридическую действительность соглашения.
Необходимые проверки
- Определить права подписи, лимиты расходов и управление ключами.
- Отличать сбой RPC от ожидающей, неуспешной или реорганизованной транзакции.
- Если оракул поставляет внешние факты, оценить источники, управление и возможные ошибки.
Источники
- Ethereum · JSON-RPC API
- Ethereum · Transactions
- Ethereum · Gas and fees
- Ethereum · Smart contracts
- Ethereum · Oracles
Редакционная проверка: 31 октября 2026 года.
Разделение отправленных, включенных и интерпретированных транзакций.
Идентификатор транзакции не определяет предполагаемый эффект. Проверьте сеть, квитанцию, включение, статус и соответствующее бизнес-событие. Определите политику подтверждения и восстановления для используемой цепочки; интерфейс не должен сообщать об успехе, пока результаты остаются неопределенными.
- Проверка запрошенной сети и идентификатора.
- Разделение ожидающих, неудачных выполнений и подтвержденных эффектов.
- Проверка повторных уведомлений без повторного воспроизведения бизнес-действий.
Означает ли возвращенный хеш завершение операции?
Нет. Это идентифицирует поданную транзакцию. Для отслеживания и интерпретации результатов необходимы проверки, соответствующие цепочке и контракту; не следует слепо повторно отправлять неоднозначную операцию.
Первичный источник: Ethereum — JSON-RPC and transaction receipts. Связанный метод: прочитать практическое руководство.
Квоты и ограничения API
Ограничения влияют на ёмкость, повторы и распределение между клиентами.
- Запишите, относится ли квота к аккаунту, ключу или ресурсу, и сколько параллельных операций допускает клиент. Безграничная очередь может перегрузить сервис при невысокой средней частоте.
- При 429 учитывайте Retry-After, если он есть, и подождите перед следующим запросом. Совмещайте растущую задержку и рассредоточение клиентов с пределом попыток и общим сроком.
- После потери ответа на запись проверьте состояние до повтора. В имитации сочетайте квоты, поздние ответы и отмену: очередь должна завершиться без повторных эффектов.
Воспроизводимый приёмочный случай
Вымышленный пример: данные не описывают клиента или наблюдаемый результат.
Посмотреть данные случая
{
"http_status": 429,
"retry_after_seconds": 30,
"workers": 20,
"retry_budget": 3,
"retry_budget_scope": "per_worker_retries_excluding_initial_request",
"scheduling_example": {
"response_received_at_seconds": 0,
"illustrative_retry_seconds": [
30,
31,
32,
33,
34
],
"workers_per_second": 4,
"alternative_deadline_seconds": 25,
"total_attempts_if_all_retries_used": 80
}
}Ожидаемое решение
Выдержите 30 секунд, распределите повторы 20 обработчиков и ограничьте их количество.
Двадцать клиентов: распределить и посчитать повторы
Вымышленный пример: 20 обработчиков в момент +0 s получают 429 с Retry-After: 30. Расписание показывает один вариант распределения, не гарантируя мощности сервера. У каждого есть 3 повтора помимо исходного запроса.
| Правило | Расчёт или расписание | Результат |
|---|---|---|
| Одновременный повтор | 20 × 1 = 20 @ +30 s | Ожидание 30 секунд соблюдает задержку, но все 20 запросов возвращаются вместе. Всплеск нагрузки может повториться. |
| Распределённый повтор | 4 × 5 = 20 @ +30…+34 s | Четыре запроса в секунду в течение пяти секунд распределяют 20 повторов, не уменьшая их число. Пример расписания не заменяет политику нарастающих задержек со случайным разбросом. |
| Срок 25 секунд | 25 s < 30 s → 0 | Если оставшееся время меньше требуемых 30 секунд, остановитесь или отложите запрос согласно контракту. Не сокращайте ожидание ради срока. |
| Максимальный бюджет | 20 × (1 + 3) = 80 | Все попытки дают 20 исходных запросов и 60 повторов: всего 80. Ограничение не гарантирует успеха или безопасного повторения. |
Процедура проверки
- Запишите область квоты и бюджет повторов.
- Исчерпайте квоту только в разрешённом тесте.
- Сохраните 429, Retry-After и ограниченную последовательность. Различайте техническое ограничение и результат операции: исчерпанную квоту нельзя превращать в сообщение о нулевом наличии.
- Симулируйте без внешней нагрузки четыре слоя по три общих вызова и посчитайте попытки.
- Просрочьте вымышленную задачу в очереди и проверьте отсутствие новой операции.
- Восстановите разрешённую работу постепенно после симулированного сбоя и сохраните вызовы, сроки и уникальные результаты.
Доказывает ли 429, что предыдущая запись не выполнилась?
Нет. Операция без ответа требует отдельной сверки; ответ на другую попытку не подтверждает её состояние.
Первичный источник: IETF — RFC 6585, HTTP 429. Связанный метод: прочитать практическое руководство.
API: не допускать умножения попыток между слоями
Приложение, SDK, прокси и сервис могут повторять один вызов. Четыре вымышленных слоя с тремя общими попытками каждый дают до 81 вызова неисправной зависимости. Добавьте общий бюджет и полезный срок к контролю квот.
- Опишите автоматические попытки приложения, SDK, прокси и зависимостей. Выберите ответственный слой и отключите или согласуйте дополнительные повторы. Считайте начальную попытку в бюджете. Сохраняйте ID операции и проверяйте неопределённые эффекты до неидемпотентного повтора.
- Задайте общий срок ожидания, соединения и обработки с реальными ограничениями клиента. Отклоните просроченные задачи до очереди. Локальная отмена не доказывает остановку сервера: сверяйте состояние. Восстанавливайте трафик постепенно без запуска всех очередей сразу.
Три попытки на слой означают три всего?
Нет. Четыре вымышленных слоя по три общие попытки дают до 3⁴ = 81 последнего вызова.
Истечение срока отменяет удалённый эффект?
Не обязательно. Оно предотвращает новую устаревшую работу; начатая операция требует проверки состояния и возможной компенсации.
Первичный источник: AWS — Timeouts, retries, and backoff with jitter. Связанный метод: прочитать практическое руководство.