Идентификатор цепочки Ethereum, или chain ID, задаёт контекст, которого нет в одной лишь строке адреса. Метод eth_chainId возвращает настроенное значение, используемое в предусмотренной EIP-155 схеме подписи транзакций с защитой от повторного воспроизведения. Идентификатор сети, возвращаемый методом net_version, отвечает на отдельно определённый вопрос. Если сохранять название метода рядом с результатом, два разных понятия не превратятся в одно число без пояснений.
При чтении документации полезно различать три вещи: текст адреса, тип указанного идентификатора и обсуждаемую сеть. Разберём эти различия, рассмотрим гипотетический пример и составим список проверок по уже записанным ответам. Для такого разбора не требуется подписывать запросы в кошельке или отправлять транзакции.
Chain ID и network ID отвечают на разные вопросы
В документации Ethereum JSON-RPC метод net_version определён как возвращающий текущий идентификатор сети в виде строки. Записывая результат, сохраняйте именно этот смысл: перед вами network ID, полученный от ответившего узла этим методом.
Метод eth_chainId возвращает текущий настроенный идентификатор цепочки, связанный со схемой подписи транзакций EIP-155 с защитой от повторного воспроизведения. Таким образом, документация отводит двум идентификаторам разные роли. Прежде чем объяснять число, нужно установить, какой метод его сообщил.
Сравнение чисел не заменяет определения. Даже если в записи результаты численно совпадают, поля стоит оставить раздельными: «chain ID из eth_chainId» и «network ID из net_version». Совпадение само по себе не объясняет, почему были настроены именно такие значения, и не делает назначения методов одинаковыми.
Как читать формат и контекст ответа
EIP-695 задаёт для результата eth_chainId строковое представление целого числа в шестнадцатеричном формате. Например, запись 0x1 означает единицу. При сравнении сохранённых результатов важно различать способ записи и само число: разный вид записи ещё не означает разные значения.
Для определения цепочки, с которой происходит взаимодействие, предложение рекомендует предпочитать eth_chainId методу net_version. Эта рекомендация предполагает корректную реализацию. Ссылка на стандарт сама по себе не подтверждает подлинность конкретного RPC-сервиса и не устанавливает его безопасность.
У ответа есть и определённый контекст. Возвращаемый chain ID должен соответствовать информации в последнем блоке, известном клиенту, то есть в текущей известной ему вершине цепочки. Это требование спецификации к реализации, а не доказательство того, что любой отдельно взятый ответ ему соответствует.
EIP-695 также описывает особый случай: если текущий известный клиенту последний блок не задаёт chain ID, клиент должен ответить так, будто метод не поддерживается, и вернуть подходящую ошибку. Здесь важно сохранить условие. Произвольная ошибка запроса ещё не устанавливает, что возникла именно такая ситуация. В учебном разборе лучше отметить невыясненную ошибку, чем подставить предполагаемый идентификатор.
Какова роль chain ID в защите от повторного воспроизведения
EIP-155 описывает защищённую схему хеширования данных транзакции, которая включает идентификатор цепочки. В спецификации указаны условия её применения: номер блока достиг порога активации предложения, а значение chain ID доступно. Для понимания темы достаточно знать место идентификатора в этой схеме; разбирать создание и подписание транзакции здесь не требуется.
Предложение также сохраняет ранее существовавшую схему подписи со значениями v, равными 27 и 28, по её прежним правилам. Это положение о совместимости внутри EIP-155. Из него нельзя заключить, какова действующая политика приёма таких транзакций у каждой цепочки или каждого клиента.
Будущим тестовым сетям, консорциумным и альтернативным цепочкам Ethereum, принимающим EIP-155, предлагается выбирать уникальные chain ID. Однако рекомендация выбирать уникальные значения не доказывает, что все независимые цепочки действительно ей следуют.
Из этих положений следует ограниченный логический вывод: разделение по chain ID, о котором идёт речь в EIP-155, зависит от использования защищённой схемы и разных значений идентификатора. Основания вывода таковы: защищённая схема включает chain ID, прежняя схема сохраняется в предложении, а участникам рекомендуется выбирать разные идентификаторы.
Эти основания не устанавливают такую же защиту для сохранённой старой схемы, для цепочек с одинаковым ID или для любых видов подписанных запросов. Поэтому формулировка «chain ID обеспечивает защиту всех подписей» была бы шире того, что подтверждают рассмотренные положения.
Почему привычный вид адреса не определяет цепочку
Документация об аккаунтах Ethereum описывает адрес внешнего аккаунта, или EOA, как 20-байтовое значение: 40 шестнадцатеричных символов и дополнительный префикс 0x. Это описание представления адреса, а не указание его сетевого контекста.
Отдельно документация о сетях Ethereum объясняет, что независимые сети могут соответствовать одному протоколу и при этом не взаимодействовать друг с другом. А EIP-695 определяет отдельный метод получения идентификатора цепочки — eth_chainId.
Соединяя эти три положения, получаем логический вывод: гипотетическая строка адреса с описанным синтаксисом сама по себе не позволяет установить цепочку. Формат строки не выбирает одну из независимых сетей. Это вывод из совокупности источников, а не прямая цитата со страницы об аккаунтах.
Вывод касается только идентификации. Он ничего не утверждает о равенстве балансов, развёртывании контрактов, наличии средств, контроле через приватный ключ или возможности восстановления активов в разных сетях. Такие вопросы нельзя разрешить одной проверкой того, что адрес выглядит привычно.
Гипотетический пример: одна строка на двух карточках
Представим две вымышленные учебные карточки — А и Б. На обеих указан адрес 0x1111111111111111111111111111111111111111. По условию примера карточка А содержит записанный результат eth_chainId, равный 0x65, а карточка Б — 0xca. Это гипотетические исходные данные, без утверждений о работающих RPC-сервисах или существующих аккаунтах.
Повторяющаяся строка задаёт одинаковое представление адреса на двух карточках. Заданные результаты eth_chainId указывают разные контексты цепочки. Согласно предыдущему выводу, одного текста адреса недостаточно, чтобы решить, цепочка какой карточки имеется в виду.
Теперь мысленно закроем поля chain ID. Видимый синтаксис адреса останется прежним, но явный контекст цепочки исчезнет. Если открыть поля, различие снова станет читаемым. Пример показывает, какую информацию добавляет отдельный идентификатор; он не приписывает адресу баланс, не устанавливает наличие контракта и не определяет владельца аккаунта.
Полезный результат такого упражнения — запись с понятными подписями полей. Вместо заметки «адрес и число» получится «адрес, название метода и возвращённый идентификатор». Тогда при повторном чтении не придётся угадывать, что означало число и к какой карточке относилось.
Список проверок без подписания и отправки транзакций
- Обозначьте нужный контекст. Запишите, о какой цепочке идёт речь, прежде чем интерпретировать адрес.
- Сохраните названия методов. Уже имеющийся результат
eth_chainIdотметьте как chain ID, а результатnet_version— как network ID. - Различайте запись и значение. При сравнении шестнадцатеричных результатов сопоставляйте представленные числа, а не только внешний вид строк.
- Учитывайте условия ответа. Помните о требовании соответствовать последнему известному клиенту блоку. Не заменяйте невыясненную ошибку догадкой.
- Ограничивайте выводы о защите. Для обсуждаемого разделения по chain ID нужны защищённая схема EIP-155 и разные значения идентификатора.
- Оставляйте синтаксису адреса его роль. Он описывает представление строки; цепочку устанавливают отдельно.
Этот список подходит для чтения документации и разбора сохранённых ответов. Он не требует добавления RPC-сервисов, подписи в кошельке или отправки транзакции.
Образовательный материал подготовлен с помощью ИИ. Гипотетический пример служит для объяснения различий, описанных в первичных источниках.
Материал по смежной теме: Адрес кошелька, приватный ключ и фраза восстановления: в чём разница?.