---
title: "RPC-узел"
description: "RPC-узел предоставляет кошелькам и приложениям интерфейс запросов и ответов для чтения данных блокчейна и трансляции транзакций. Узнайте, что можно и нельзя исправить сменой конечной точки и как снизить риски доступности, конфиденциальности и безопасности."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# RPC-узел
> Только в образовательных целях; не является инвестиционной рекомендацией. Неверная или вредоносная конечная точка RPC может раскрыть активность, вернуть вводящие в заблуждение данные или нарушить отправку транзакций; операции с цифровыми активами могут привести к необратимым потерям.
## Краткий ответ
RPC-узел — это узел блокчейна либо служба перед одним или несколькими узлами, которая принимает удалённые вызовы процедур от кошельков, обозревателей и приложений. В сетях, совместимых с Ethereum, обычно используется интерфейс JSON-RPC. Он позволяет программе читать данные узла, моделировать вызовы, оценивать gas и передавать подписанные байты транзакции для распространения без собственного узла.
URL, настроенный в кошельке, — это **конечная точка RPC**, а не сам блокчейн. Её смена может обойти сбой провайдера, отставание узла, ограничение частоты, неподдерживаемый метод или проблему соединения. Она не изменит правила контракта, не восстановит отменённую транзакцию, не обратит подтверждённый перевод и не устранит остановку всей сети. Новая точка должна обслуживать нужную сеть и правильный ID цепочки.
## Как это работает
Клиент отправляет запрос через поддерживаемый транспорт, например HTTP или WebSocket. Запрос JSON-RPC называет метод, передаёт параметры и содержит идентификатор, который повторяется в ответе. Узел выполняет метод на основе своего локального представления цепочки и возвращает результат или ошибку. Соединение WebSocket также может поддерживать подписки, если клиент и точка их предоставляют.
Методы чтения имеют разный смысл и требования к данным. Например, `eth_blockNumber` сообщает последний известный узлу блок, а `eth_getBalance` читает баланс адреса на заданной метке или номере блока. Результаты исправных узлов могут временно расходиться из-за различий в вершине цепочки, пуле ожидающих транзакций, режиме обрезки или расширениях. Хостинг-провайдер также может вводить аутентификацию, квоты, ограничения размера или методов, которые не являются правилами консенсуса.
При обычной транзакции кошелёк формирует и подписывает её локально, затем отправляет подписанные байты через `eth_sendRawTransaction`. RPC-узел проверяет запрос и пытается распространить транзакцию среди пиров. Возвращённый хеш означает, что узел принял байты к отправке; он не доказывает включение, успех или финальность. Включение и состояние следует независимо проверить в правильной цепочке.
Таким образом, конечная точка — это зависимость доверия и доступности. Она может видеть запрашиваемые адреса, IP-данные, время и отправленные транзакции; пропускать или задерживать данные; показывать устаревшее или неполное состояние. Криптографическая подпись не даёт незаметно изменить правильно подписанную транзакцию, но не гарантирует правдивость ответов на чтение и не защищает неподписанные метаданные и конфиденциальность.
## Пример
Кошелёк может запросить номер блока у клиента исполнения Ethereum:
```json
{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}
```
Корректный ответ может выглядеть так:
```json
{"jsonrpc":"2.0","id":1,"result":"0x12ab34"}
```
Шестнадцатеричный результат — последний номер блока, известный этой точке. Если обычный провайдер не отвечает вовремя, а вторая надёжная точка возвращает более новый блок и ожидаемый ID цепочки, переключение может восстановить запросы баланса и отправку транзакций. Если обе показывают одну и ту же квитанцию об отмене, смена RPC не изменит результат в блокчейне.
## Риски и меры контроля
- **Неверная сеть:** скопированная точка может обслуживать другую цепочку или форк. До подписания независимо проверьте ID цепочки, название сети, нативный актив и свежий блок.
- **Ложные или устаревшие данные:** неисправная или вредоносная точка может вернуть старый баланс, пропустить журналы или исказить симуляцию. Сравнивайте важные данные с другим провайдером или собственным узлом и фиксируйте конкретный блок для воспроизводимости.
- **Утечка конфиденциальности:** запросы могут связать активность кошелька с сетевыми метаданными. Не отправляйте лишние адреса, изучайте политику хранения и рассмотрите доверенную собственную точку, если конфиденциальность оправдывает эксплуатационные затраты.
- **Цензура или задержка:** точка может отказаться транслировать или задержать транзакцию. Сохраните подписанный хеш, проверьте независимые обозреватели или узлы и используйте второй надёжный путь, если транзакции нет. Не подписывайте замену без проверки nonce и последствий для комиссии.
- **Раскрытые учётные данные:** ключи API в открытом коде могут украсть и исчерпать квоту. Ограничивайте ключи по источнику или службе, не храните привилегированные данные в клиенте и меняйте скомпрометированные ключи.
- **Опасное раскрытие узла:** публикация административного или широко включённого RPC увеличивает поверхность атаки. По умолчанию привязывайте собственный RPC локально, открывайте только нужные пространства имён, добавляйте аутентификацию и сетевой контроль и никогда не раскрывайте разблокированные счета.
- **Обман кошелька:** URL точки не требует сид-фразы или закрытого ключа. Откажитесь от службы, которая их запрашивает, проверяйте поля транзакции в кошельке и не определяйте целевой контракт только по ответу RPC.
## Распространённые заблуждения
- **«RPC — это блокчейн».** Это интерфейс к представлению блокчейна, которое хранит узел.
- **«Хеш транзакции означает подтверждение».** Обычно он доказывает лишь принятие подписанных байтов точкой; исполнение и финальность — отдельные этапы.
- **«Смена RPC меняет комиссии или контракт».** Она может изменить оценки или качество доступа, но фактическое исполнение определяют транзакция и правила протокола.
- **«Все точки возвращают одинаковые данные».** Могут различаться синхронизация, ожидающие пулы, сохранённая история, расширения и правила провайдера.
- **«HTTPS делает каждый ответ надёжным».** HTTPS защищает соединение с указанным сервером, но не доказывает полноту или правильность его данных блокчейна.
## Связанные темы
- [Полный узел](/crypto/full-node/)
- [Блокчейн](/crypto/blockchain/)
- [Мемпул](/crypto/mempool/)
- [RPC приватных транзакций](/crypto/private-transaction-rpc/)
- [Обозреватель блоков](/crypto/block-explorer/)
## Источники
- [API JSON-RPC](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (дата обращения: 2026-08-21)
- [Спецификация API исполнения](https://ethereum.github.io/execution-apis/docs/quickstart/) - Ethereum Execution APIs (дата обращения: 2026-08-21)
- [Сервер JSON-RPC](https://geth.ethereum.org/docs/interacting-with-geth/rpc) - go-ethereum (дата обращения: 2026-08-21)
- [Запуск собственного узла Ethereum](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (дата обращения: 2026-08-21)
Source: https://wiki.fcontext.com/ru/crypto/rpc-node/index.mdx