# Blockchain RPC

Blockchain RPC позволяет приложению обращаться к поддерживаемым блокчейн-сетям без развёртывания собственных узлов. Подключайтесь по HTTP JSON-RPC или нативному gRPC с RPC-ключом рабочего пространства; протокол и способ выбора сети зависят от блокчейна.

HTTP `rpc.vilna.io`
gRPC `grpc.vilna.io:443`
`vilna_rpc_` · пространство
Один ключ, все сети

## Протоколы 

Два протокола, выбираются по сети:

- **[JSON-RPC через HTTP](/ru/apis/rpc/json-rpc)** - EVM-сети, Solana и Bitcoin. Стандартный JSON-RPC 2.0 по HTTPS.
- **[gRPC](/ru/apis/rpc/grpc)** - Tron. Нативный gRPC с маршрутизацией сети через metadata.


## Аутентификация 

Каждый аутентифицированный запрос несёт RPC-ключ (префикс `vilna_rpc_`), созданный в настройках рабочего пространства. Заголовок зависит от протокола:

| Протокол | Заголовок | Значение |
|  --- | --- | --- |
| HTTP | `X-Api-Key` | Ваш RPC-ключ |
| gRPC | `x-api-key` (metadata) | Ваш RPC-ключ |


RPC-ключи привязаны к рабочему пространству и охватывают все сети. См. [Аутентификацию](/ru/apis/authentication) про типы ключей и области.

## Поддерживаемые сети 

11 сетей, все по JSON-RPC, кроме Tron, который работает по gRPC. В [таблице сетей](/ru/apis/networks#table) перечислены CAIP-2 идентификаторы и алиасы каждой, и видно, какие из них отслеживает и Platform API.

Идентификация сети
Для JSON-RPC указывайте CAIP-2 ID или алиас в пути HTTP, для Tron - в metadata `x-chain-id` gRPC. CAIP-2 идентификаторы Tron и Solana из [таблицы сетей](/ru/apis/networks#columns) поддерживаются вместе с алиасами и идентификаторами вида `tron:mainnet` и `solana:mainnet`. Формат CAIP-2 разобран в [Стандартах](/ru/apis/standards#caip).

## Проверка доступности 

Эндпоинт `GET /chains` не требует ключа и возвращает сети, которые сейчас обслуживает прокси - быстрый способ убедиться, что сервис доступен:

```bash
curl https://rpc.vilna.io/chains
```

## Повторы и неизвестный результат 

Гарантии HTTP-идемпотентности Vilna не распространяются на RPC. Запросы могут выполняться повторно, в том числе при автоматическом повторе прокси. После таймаута или потери ответа на отправку транзакции сначала проверьте её ID и состояние в сети, затем решайте, нужна ли повторная отправка. Не подписывайте новую транзакцию автоматически: исходная уже могла попасть в сеть.