Где проходит граница доверия
- Private key остаётся в кошельке, а RPC получает публичные запросы и уже подписанную транзакцию; нормальному провайдеру не нужен seed.
- Full, light и archive node отвечают на разные классы запросов. Слово «узел» ещё не обещает доступ ко всей истории состояний.
- Если интерфейс и explorer расходятся, нужно сверить сеть, block number, RPC endpoint и transaction hash, а не отправлять операцию повторно вслепую.
Кошелёк хранит право подписи, а не копию всей сети
В self-custody wallet секрет нужен, чтобы подписать действие. Баланс, nonce, код и storage контракта входят в состояние выбранного блока, а receipt и события хранятся отдельно среди данных исполнения транзакций. Чтобы показать всё это на экране, приложение обращается к узлу. Поэтому один и тот же адрес может корректно подписывать операции даже тогда, когда конкретный интерфейс временно не обновляет баланс.
Эта граница объясняет важное правило: смена RPC не переносит активы и не создаёт новый адрес. Она меняет источник, через который приложение читает и отправляет публичные данные. Seed-фраза, private key и запрос на подпись для такой смены не нужны. Если сайт под видом «ремонта RPC» просит секрет кошелька, он решает совсем другую задачу — получает контроль над аккаунтом.
| Элемент | Где появляется | Что может узнать RPC |
|---|---|---|
| Private key или signing credential | Локальное хранилище или отдельное устройство | Не должен передаваться узлу |
| Адрес и chain ID | Параметры аккаунта и выбранной сети | Виден в запросах баланса и транзакциях |
| Баланс и nonce | Состояние выбранного блока | Возвращается узлом по публичному адресу |
| Unsigned transaction | Собирается приложением | Может симулироваться через eth_call или estimateGas |
| Signed raw transaction | Подписывается кошельком | Получается узлом для проверки и распространения |
- Элемент
- Private key или signing credential
- Где появляется
- Локальное хранилище или отдельное устройство
- Что может узнать RPC
- Не должен передаваться узлу
- Элемент
- Адрес и chain ID
- Где появляется
- Параметры аккаунта и выбранной сети
- Что может узнать RPC
- Виден в запросах баланса и транзакциях
- Элемент
- Баланс и nonce
- Где появляется
- Состояние выбранного блока
- Что может узнать RPC
- Возвращается узлом по публичному адресу
- Элемент
- Unsigned transaction
- Где появляется
- Собирается приложением
- Что может узнать RPC
- Может симулироваться через eth_call или estimateGas
- Элемент
- Signed raw transaction
- Где появляется
- Подписывается кошельком
- Что может узнать RPC
- Получается узлом для проверки и распространения
Узел не просто хранит базу — он перепроверяет переходы состояния
Путь данных внутри Ethereum node
- Клиенты получают transactions, blocks и attestations
Execution и consensus clients работают со своими peer-to-peer сетями и синхронизируют относящиеся к ним данные.
- EVM повторяет вычисления
Execution client проверяет transactions, исполняет код и убеждается, что предложенное изменение state следует правилам протокола.
- Consensus client отслеживает canonical head и finality
Он применяет fork-choice и сведения об attestations, а не просто принимает самый свежий ответ внешнего API.
- Приложение получает представление проверенного состояния
Execution client открывает методы для чтения блоков, state и receipts, симуляции calls и отправки подписанных transactions.
После перехода Ethereum на Proof of Stake полноценный узел использует связку execution client и consensus client. Validator — отдельная роль поверх этой связки: обычному пользователю не нужно вносить 32 ETH или предлагать блоки, чтобы запустить проверяющий node и пользоваться собственным RPC.
Один endpoint отвечает на чтение, симуляцию и отправку — но это разные операции
| Задача | Пример метода | Что означает ответ |
|---|---|---|
| Узнать баланс | eth_getBalance | Количество native asset у адреса на выбранном block tag |
| Прочитать token balance | eth_call | Локально исполненный read-only вызов contract в заданном state |
| Оценить gas | eth_estimateGas | Оценка для конкретного call при текущих входных данных, не гарантия успеха позже |
| Получить receipt | eth_getTransactionReceipt | Результат уже включённой transaction или null, если receipt ещё недоступен |
| Передать подпись | eth_sendRawTransaction | Узел принял байты для проверки и распространения; это ещё не inclusion и не finality |
- Задача
- Узнать баланс
- Пример метода
- eth_getBalance
- Что означает ответ
- Количество native asset у адреса на выбранном block tag
- Задача
- Прочитать token balance
- Пример метода
- eth_call
- Что означает ответ
- Локально исполненный read-only вызов contract в заданном state
- Задача
- Оценить gas
- Пример метода
- eth_estimateGas
- Что означает ответ
- Оценка для конкретного call при текущих входных данных, не гарантия успеха позже
- Задача
- Получить receipt
- Пример метода
- eth_getTransactionReceipt
- Что означает ответ
- Результат уже включённой transaction или null, если receipt ещё недоступен
- Задача
- Передать подпись
- Пример метода
- eth_sendRawTransaction
- Что означает ответ
- Узел принял байты для проверки и распространения; это ещё не inclusion и не finality
Full, light и archive описывают объём проверки и истории, а не «качество интернета»
Full node проверяет блоки и поддерживает актуальное состояние. Light client экономит ресурсы: проверяет ограниченную часть данных и запрашивает остальное у полных узлов в рамках своей модели. Archive node дополнительно держит готовые historical states — например, чтобы быстро ответить, каким был token balance на старом блоке. Это не то же самое, что обычная история transactions: full node может хранить старые блоки, но не иметь мгновенного индекса состояния для любой высоты.
Какой источник нужен для конкретного вопроса
- текущий баланс и receipt обычно обслуживает синхронизированный full node;
- баланс или contract storage на далёком старом block number может потребовать archive state;
- сложная аналитика по миллионам events чаще требует indexer, а не серии сырых RPC-запросов;
- light client уменьшает локальные ресурсы, но его гарантии зависят от того, что именно он проверяет сам;
- block explorer добавляет индексы и интерфейс, но его экран не становится частью consensus.
Managed RPC убирает серверную работу и добавляет внешнюю зависимость
| Вопрос | Собственный узел | Managed RPC |
|---|---|---|
| Обслуживание | Синхронизация, обновления, диски и monitoring на владельце | Инфраструктуру поддерживает provider |
| Доступность | Зависит от домашнего или собственного контура | Зависит от endpoint, quota, routing и аккаунта provider |
| Проверка | Client локально проверяет правила сети | Пользователь доверяет ответу выбранной service boundary |
| Наблюдаемость запросов | Можно контролировать собственные logs | Provider технически получает запросы к своему API |
| Исторические данные | Зависят от режима и индексов node | Зависят от тарифа и поддерживаемых methods |
- Вопрос
- Обслуживание
- Собственный узел
- Синхронизация, обновления, диски и monitoring на владельце
- Managed RPC
- Инфраструктуру поддерживает provider
- Вопрос
- Доступность
- Собственный узел
- Зависит от домашнего или собственного контура
- Managed RPC
- Зависит от endpoint, quota, routing и аккаунта provider
- Вопрос
- Проверка
- Собственный узел
- Client локально проверяет правила сети
- Managed RPC
- Пользователь доверяет ответу выбранной service boundary
- Вопрос
- Наблюдаемость запросов
- Собственный узел
- Можно контролировать собственные logs
- Managed RPC
- Provider технически получает запросы к своему API
- Вопрос
- Исторические данные
- Собственный узел
- Зависят от режима и индексов node
- Managed RPC
- Зависят от тарифа и поддерживаемых methods
Ethereum.org подчёркивает, что node service не должен хранить private keys. Это не делает все endpoints одинаковыми: отличаются supported chains, block freshness, rate limits, archive access и политика журналирования. Для продукта полезны минимум два независимых пути чтения и явная проверка chain ID, но голосование большинства случайных публичных RPC само по себе не превращает ответ в consensus proof.
Расхождение экранов разбирают от сети и блока, а не от суммы
- Сверьте chain ID и название сети: одинаковый формат адреса не означает одно состояние.
- Проверьте, до какого block number синхронизирован каждый источник и не показывает ли интерфейс cached data.
- Откройте transaction hash в независимом explorer той же сети и прочитайте receipt, status и logs.
- Для ERC-20 проверьте contract address токена: ticker и картинка не идентифицируют контракт.
- Если receipt уже успешен, не создавайте второй перевод только потому, что один интерфейс не обновил портфель.
- Если raw transaction не попала в сеть, выясните nonce и статус до новой подписи с той же бизнес-целью.
Публичный explorer помогает собрать факты по hash, но не видит внутреннюю причину сбоя конкретного RPC-провайдера. Полезный результат диагностики — назвать одну сеть, один block context, один transaction hash и источник каждого ответа. Тогда становится понятно, сломалась ли витрина, отстал endpoint или сама операция ещё не включена.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Ethereum.org — nodes and clients Ethereum Foundation · Проверено 15 августа 2026 г. в 00:34 GMT+5
- Ethereum.org — node architecture Ethereum Foundation · Проверено 15 августа 2026 г. в 00:34 GMT+5
- Ethereum.org — JSON-RPC API Ethereum Foundation · Проверено 15 августа 2026 г. в 00:34 GMT+5
- Ethereum.org — light clients Ethereum Foundation · Проверено 15 августа 2026 г. в 00:34 GMT+5
- Ethereum.org — archive nodes Ethereum Foundation · Проверено 15 августа 2026 г. в 00:34 GMT+5
- Ethereum.org — nodes as a service Ethereum Foundation · Проверено 15 августа 2026 г. в 00:34 GMT+5