Quick recommendation: Do you need a dedicated TON node?
Before diving into setup and provider details, decide whether a dedicated node is the right investment for your project. A dedicated TON node gives you a single-tenant instance with your own RPC endpoint, but it also means you take on more operational responsibility and cost.
Consider a dedicated node if:
- Your application has sustained traffic that regularly hits shared endpoint rate limits.
- You need low-latency access for time-sensitive operations like trading or gaming.
- You require custom node configuration, such as archive mode or specific ADNL settings.
- You want to avoid noisy-neighbor effects from other users on shared infrastructure.
- You need predictable performance for production SLAs.
If your project is still in development or has modest traffic, a shared RPC endpoint may be sufficient. OnFinality offers both shared and dedicated options, so you can start with a shared endpoint and upgrade as your needs grow. Check the supported RPC networks page to see TON availability.
What is a dedicated TON node?
A dedicated TON node is a full node that runs exclusively for your project. Unlike shared nodes, where multiple users share the same compute resources, a dedicated node is isolated, giving you full control over the node's configuration and performance.
TON nodes come in different modes:
- Full node: Stores the latest blockchain state and serves data to lite-clients. It prunes older blocks to manage storage.
- Archive node: Stores the entire blockchain history, including old blocks and states. Required for explorers and analytics services.
- Validator node: Participates in consensus and block production. Usually not needed for RPC purposes.
For most RPC use cases, a full node or archive node is what you need. A dedicated node gives you a private endpoint that you can use for your dApp, wallet, or backend service.
Dedicated vs shared TON nodes: What's the difference?
The main difference between dedicated and shared nodes is resource isolation. With a shared node, you share CPU, memory, and network bandwidth with other users. This can lead to performance variability and rate limits. A dedicated node gives you exclusive access to the hardware, so you get consistent performance and clear rate limits (within the hardware's capacity).
Here's a quick comparison:
| Aspect | Shared Node | Dedicated Node |
|---|---|---|
| Resource isolation | Shared with others | Exclusive to you |
| Rate limits | Common | clear rate limits (hardware-bound) |
| Performance | Variable | Consistent |
| Configuration | Limited | Full control |
| Cost | Lower | Higher |
| Operational effort | Provider handles | More responsibility |
How to evaluate a dedicated TON node provider
When choosing a provider for a dedicated TON node, consider the following criteria:
- Node type: Does the provider offer full, archive, and validator nodes? Do you need archive mode for historical data?
- Protocol support: TON uses ADNL (Abstract Datagram Network Layer) for low-level communication. Does the provider support ADNL in addition to the standard HTTP API?
- Hardware specifications: What CPU, RAM, and storage are allocated? NVMe storage is important for fast state access.
- Geographic location: Where are the data centers? Choose a location close to your users to reduce latency.
- Support and maintenance: Who handles node updates, monitoring, and troubleshooting? Direct engineering access can be valuable.
- Pricing model: Is it a flat monthly fee or usage-based? Are there overage charges?
OnFinality's dedicated node service provides isolated infrastructure with flexible configuration. You can also compare pricing on the RPC pricing page.
Setting up a dedicated TON node: What to expect
Setting up a dedicated TON node involves several steps:
- Choose your node type: Decide between full, archive, or validator.
- Select a provider: Pick a provider that meets your requirements.
- Provision the node: The provider deploys the node on dedicated hardware.
- Sync the blockchain: The node downloads and verifies the blockchain state. This can take hours or days depending on the mode.
- Configure access: Set up your RPC endpoint, API keys, and security settings.
- Monitor and maintain: Keep the node updated and monitor its health.
Many providers offer managed dedicated nodes, where they handle the setup and maintenance for you. This can save time and reduce operational overhead.
TON RPC endpoint example
Once your dedicated node is running, you can interact with it using standard JSON-RPC calls. Here's an example using curl to get the latest block:
curl -X POST https://your-dedicated-endpoint.ton -H "Content-Type: application/json" -d '{
"jsonrpc": "2.0",
"method": "ton_getBlock",
"params": [{"workchain": -1, "shard": -9223372036854775808, "seqno": 123}],
"id": 1
}'
Note that TON's RPC methods differ from Ethereum's. You'll use methods like ton_getBlock, ton_getTransaction, and ton_sendMessage. For a full list, refer to the TON documentation.
Common pitfalls and troubleshooting
Running a dedicated TON node comes with its own challenges:
- Sync issues: If your node falls behind, it may take time to catch up. Ensure you have enough storage and bandwidth.
- ADNL configuration: ADNL is a low-level protocol that requires careful setup. If you're not familiar, consider using a provider that supports it.
- Rate limiting: Even with a dedicated node, your provider may impose limits. Clarify this before signing up.
- Maintenance windows: Providers may schedule maintenance that could affect availability. Ask about their policies.
If you encounter issues, check the node logs and ensure your configuration matches the provider's recommendations.
Key Takeaways
- A dedicated TON node provides exclusive resources and a private RPC endpoint, ideal for production workloads.
- Choose between full, archive, and validator nodes based on your use case.
- Evaluate providers on hardware, protocol support, location, and support.
- Managed dedicated nodes can reduce operational burden.
- Always clarify rate limits and maintenance policies before committing.
Frequently Asked Questions
What is the difference between a full node and an archive node on TON?
A full node stores the latest blockchain state and prunes older blocks, while an archive node stores the entire history. Archive nodes are needed for explorers and historical data queries.
Do I need a dedicated TON node for a small dApp?
Probably not. Shared endpoints are often sufficient for development and low-traffic applications. You can upgrade to a dedicated node when your traffic grows.
Can I run a TON validator node as an RPC endpoint?
Yes, but validator nodes have additional responsibilities and may not be optimized for RPC serving. It's usually better to run a separate full node for RPC.
How long does it take to sync a TON archive node?
Sync time varies based on hardware and network conditions. It can take several days for an archive node. Providers may offer snapshots to speed up the process.
What is ADNL and why is it important for TON?
ADNL (Abstract Datagram Network Layer) is a secure, low-level communication protocol used by TON. Some advanced use cases require ADNL support, so check if your provider offers it.
Related resources
Originally published at OnFinality.
Top comments (0)