eth_call выполняет вызов контракта на выбранном состоянии Ethereum, не создавая транзакцию в блокчейне. У транзакции другой путь: она служит механизмом инициирования изменения состояния сети, требует распространения и включения в проверенный блок. Поэтому результат симуляции полезен для оценки конкретного вызова, но не гарантирует успеха последующей транзакции.
Чтобы понять разницу между eth_call и транзакцией, нужно рассматривать вместе три вещи: проверяемую операцию, выбранное состояние и смысл полученного ответа. Если интерфейс сообщает об успешной предварительной проверке, при описании результата важно сохранить эти условия. Без них легко приписать симуляции больше доказательной силы, чем у неё есть.
Исполнение без сохранения изменений в блокчейне
В документации Ethereum JSON-RPC метод eth_call описан как выполнение вызова без создания транзакции в блокчейне. Вычисления при этом происходят: запрос не остаётся просто описанием действия, которое никто не исполнял.
Здесь принципиально различать исполнение и сохранение результата. Документация о транзакциях определяет транзакцию как механизм, через который аккаунт инициирует обновление состояния сети. Из сочетания этих положений следует вывод: eth_call не записывает изменения моделируемой операции в состояние блокчейна Ethereum.
В этом контексте выражение «только чтение» относится к воздействию на сохраняемое состояние блокчейна. Оно не означает, что код контракта во время симуляции не выполняется. Даже если рассматриваемая операция предназначена для изменения хранимых данных, важно отдельно установить, становится ли это изменение частью состояния сети.
Поэтому сообщение об успешном исполнении вызова и утверждение о сохранённом изменении отвечают на разные вопросы. Первое описывает вычисление в заданных условиях. Для второго нужны основания, выходящие за пределы результата eth_call.
Выбранный блок — часть смысла результата
Запрос eth_call принимает параметр выбора блока. Документированные варианты включают целочисленный номер блока и метки latest, earliest, pending, safe и finalized. В описании JSON-RPC указано, что параметр блока определяет высоту блока при запросе состояния Ethereum.
Отсюда следует практический вывод: сведения о выбранном блоке нужно сохранять рядом с результатом. Запись о возвращённом значении без контекста состояния неполна. Более точное описание указывает и значение, и параметр блока, использованный при вычислении.
Это вывод из устройства запроса, а не утверждение, что разные варианты выбора блока обязательно дадут разные ответы. Два результата могут совпасть. Совпадение само по себе не делает выбранное состояние несущественным для объяснения того, что именно проверялось.
Метка pending также не доказывает включения транзакции в проверенный блок. Она задаёт запрашиваемый контекст состояния. Выбор этой метки не превращает вызов в транзакцию и не устанавливает факт её включения.
Какие параметры вызова нужно учитывать
Выбранное состояние — лишь одна часть запроса. Объект вызова также описывает адрес назначения и передаваемые данные. Для осмысленного сравнения результатов полезно сохранять следующие поля:
- from: необязательный адрес отправителя в контексте вызова.
- to: адрес, которому направлено исполнение.
- input: необязательное поле, задающее вызываемый метод и его закодированные параметры.
- value: необязательное значение, передаваемое в контексте вызова.
- gas: необязательный параметр контекста исполнения, который может понадобиться при некоторых вызовах.
Эти поля следует понимать в рамках определения eth_call. Хотя отдельные описания параметров используют терминологию транзакций, сам метод явно выполняется без создания транзакции в блокчейне. Поэтому наличие from не доказывает подписания, авторизации или распространения транзакции. Наличие value не доказывает сохранённого в блокчейне перевода.
Из этого следует правило для чтения отчётов: прежде чем считать два результата ответами на один вопрос, сопоставьте записанный контекст. Сохраните адрес назначения, входные данные, указанные адрес отправителя и значение, а также параметр блока. Если gas передан, сохраните его как часть записанного контекста вызова.
Правило не утверждает, что изменение любого поля обязательно изменит ответ. Оно помогает удержать условия, на которых основано объяснение. Если часть параметров неизвестна, корректнее обозначить этот пробел, чем предположить полное совпадение двух проверок.
Гипотетический пример: счётчик, вызов и транзакция
Рассмотрим вымышленный учебный контракт с хранимым счётчиком, равным 7. По условию примера операция setEight при успешном исполнении устанавливает счётчик в 8 и возвращает 8. Это явно заданные учебные предположения, а не описание существующего контракта или наблюдаемой операции.
Вариант с eth_call
Предположим, eth_call успешно выполняет эту операцию на выбранном состоянии и возвращает предусмотренное условием значение 8. Ответ относится к этому исполнению. Моделируемое обновление счётчика не сохраняется: сам вызов не изменил хранимый в блокчейне счётчик с 7 на 8.
Это применение ранее сделанного вывода об отсутствии сохранения моделируемых изменений. Возвращённое число нужно отличать от числа, записанного в постоянном состоянии. Вымышленная операция может вернуть 8 при вычислении, но один этот ответ не доказывает обновления счётчика в сети.
Вариант с транзакцией
Теперь рассмотрим отдельную гипотетическую транзакцию, вызывающую ту же операцию. Допустим, её распространили, включили в проверенный блок и успешно исполнили. При этих предположениях транзакция сохраняет обновление счётчика до 8.
Это вывод из документированного различия между вызовом и транзакцией, применённый к вымышленному поведению контракта. Включение в блок и успешное исполнение здесь заданы условиями. Они не являются следствиями, которые гарантировал предыдущий результат eth_call. Сравнение объясняет два способа исполнения, не предлагая выполнять реальную операцию.
Почему успешная симуляция не доказывает включения
Документация Ethereum о транзакциях объясняет, что транзакции, изменяющие состояние EVM, требуют распространения в сети и включения в проверенный блок. Это требования к жизненному циклу транзакции. Результат eth_call не устанавливает, что эти этапы состоялись.
Документированный ответ eth_call — возвращаемые данные исполненного контракта. Это описание не обещает, что любой запрос завершится успешно или предоставит содержательные данные приложения. Если возвращаемые данные получены, их смысл всё равно связан с конкретной операцией и условиями её исполнения.
Из уже установленных ограничений следует ещё один вывод: успешный вызов не гарантирует успешного исполнения последующей транзакции. Вызов проверяет заданный контекст на выбранном состоянии, не создавая транзакции в блокчейне. Последующей транзакции требуется отдельное включение. Эти основания не устанавливают, что её состояние и контекст исполнения совпадут с условиями симуляции.
Речь об отсутствии гарантии, а не о прогнозе неудачи. В описании квитанции JSON-RPC номер содержащего транзакцию блока указан отдельно от статуса успеха или ошибки. Для квитанций с полем status значение 1 обозначает успех, а 0 — ошибку. Из наличия этих отдельных полей следует ограниченный вывод: включение в блок само по себе не доказывает успешного исполнения контракта.
Подробнее эти различия разобраны в материале о том, как проверяется транзакция Ethereum и что подтверждает каждый этап. Здесь достаточно сохранить границу между результатом симуляции и сведениями об отдельной транзакции.
Список для проверки объяснения результата
- Определите вид свидетельства: запись описывает исполнение вызова или отдельно отправленную транзакцию?
- Сохраните параметр блока: укажите контекст состояния рядом с ответом.
- Учитывайте параметры вызова: сохраните адрес назначения, входные данные и указанные отправителем поля
fromиvalue. Также сохраните gas, если он передан. - Отделяйте ответ от сохранённого изменения: результат симуляции не устанавливает факт обновления состояния блокчейна.
- Проверяйте силу вывода: успех вызова, включение транзакции и успешное исполнение транзакции — разные утверждения.
- Раскрывайте условия примера: обозначьте вымышленное поведение операции и предположения об успехе транзакции.
Этот список подходит для оценки объяснений и записанных учебных примеров. Ссылки на первичную документацию обосновывают описанные различия, но сами по себе не подтверждают безопасность или корректность конкретного контракта.
Образовательный материал подготовлен с помощью ИИ. Гипотетический пример поясняет принципы исполнения и не является рекомендацией отправлять транзакцию или подписывать запрос кошелька.