Interacting with Solana from ICP
Bitcoin, Ethereum, and now Solana: Smart contracts (also known as 'containers') on the Internet Computer can interact with these three major blockchains in a completely decentralized manner, allowing developers to create unique multi-chain decentralized applications (dapps), making it no longer a dream to fully exchange SOL on-chain for BTC.
This is achieved by adding two new features to the Internet Computer, which together accomplish the Helium milestone of the ICP roadmap, thus tightening the link between Solana and ICP:
Threshold EdDSA allows the container to securely compute Ed25519 signatures, which is the signature scheme used for Solana transactions.
The SOL RPC container leverages the container's capabilities to issue HTTPS requests (HTTPS outbound) to reach the Solana blockchain through its JSON-RPC interface.
The first feature was introduced in the blog post (Unlock Chain Fusion with Schnorr and ECDSA Signatures). This article will focus on the second feature, namely the SOL RPC container.
Overview
From a very high level, the SOL RPC container provides the same service to the container as if Solana RPC nodes were directly available on the Internet Computer, allowing the container to interact with the Solana blockchain.
The container achieves this by contacting multiple JSON-RPC Solana providers through HTTPS calls and aggregating their responses to avoid single points of failure.
It operates as a service controlled by a DAO that manages the entire Internet Computer (the Network Nervous System), meaning the container can directly call the SOL RPC container without any extra setup (e.g., no API keys required), and any changes are subject to community review and approval proposals.
How to Use
The container is now live, with proposal number #136985, located on the trust subnet.
The best way to get started is to check out the codebase. Want a sneak peek? Here’s how to retrieve the latest completed slot from the Solana mainnet from the command line:
Here’s how to operate within the container:
As you can see, we have also added a client library (see the sol_rpc_client crate) so that you can easily interact with the SOL RPC container from within your container.
Don't forget to check the examples provided in the repository to see how containers on the Internet Computer send SOL or SPL tokens on Solana!
How it Works
In short, the SOL RPC container is similar to the EVM RPC container, but with one key difference (as described below):
No Single Point of Failure: The SOL RPC container exposes an interface that wraps several key Solana JSON-RPC APIs into a type-friendly Candid interface, ensuring response consistency by normalizing and comparing results from multiple providers for a given call. By default, each request will parallel query three different Solana JSON-RPC providers and require all responses to be the same. Dapps can customize their strategies for each call to meet their security requirements without relying on a single provider, for instance, they can require consensus from three out of five providers on the results.
Controlled by the Network Nervous System: The Network Nervous System (NNS) is a decentralized autonomous organization (DAO) that manages the Internet Computer, making it possible to build democratized, decentralized applications governed by the community. The SOL RPC container is an example of such an application, controlled by the NNS, meaning its governance is as secure as the governance of the entire Internet Computer. Any change to the container's code, such as changing the provider's URL, must go through a proposal that is carefully reviewed and voted on by (staked) ICP token holders, also known as neurons.
Using Cycles instead of API Keys: Most Solana JSON-RPC providers require API keys to authenticate their API calls, which in turn requires an account, usually needing a credit card, making it extremely cumbersome to use their services. Callers of the SOL RPC container do not need to manage JSON-RPC providers and their API keys; instead, they simply pay for the call using additional cycles (the native currency on the Internet Computer used to pay for resource costs, similar to gas on Ethereum).
Scalable: The SOL RPC container provides a Candid interface for some (but not all) Solana JSON-RPC endpoints. For other endpoints, the SOL RPC container provides an endpoint (jsonRequest) to send any JSON-RPC request, so you can still benefit from the SOL RPC container (e.g., querying and aggregating responses from multiple providers). If the providers offered by the SOL RPC container do not meet your use case (e.g., requiring different rate limits), you can also specify your own custom providers.
Fast Block Time - Conversion
If this sounds like the EVM RPC container, it's because they are quite similar. In fact, both leverage HTTPS calls to access another blockchain through the provided JSON-RPC interface. However, one key difference is that due to the current limitations of HTTPS calls, the SOL RPC container cannot support certain Solana JSON-RPC methods (e.g., getLatestBlockHash). To understand this issue, if you try to get the latest finalized block hash in the terminal, you may see messages like this:
Interestingly, while executing all three requests took less than 1 second, all responses were different! Now imagine 34 nodes executing that request in parallel (which is the number of nodes on the trust subnet), and you can understand what will happen: most responses will differ, and the nodes will fail to reach consensus.
On Solana, since validators vote on the main chain, and Solana's block time is very fast (around 400 milliseconds), the block height at any given commitment level (even if completed) constantly changes, meaning the rate of block height changes on Solana at any commitment level is faster than the typical latency of HTTPS outbound on the trust subnet (approximately 3 seconds).
This is actually a problem not only for getLatestBlockhash but also for many other endpoints (e.g., getSlot). However, we can use another trick: HTTPS calls can also specify a so-called conversion function that allows the node to modify received responses before consensus is reached. Since the result of getSlot is just a number, the conversion can simply use rounding (default is 20, but the caller can specify) to artificially increase the slot time, thus increasing the likelihood of reaching consensus.
One limitation of HTTPS calls is that the specified conversion is a local operation, considering only the responses received by the node. Since the result is a fixed-length random string, this is insufficient to support getLatestBlockHash. Supporting this method, and more generally, supporting any endpoint with rapidly changing responses, will require more complex conversions. For example, this may involve considering responses from other nodes to be able to use some majority or median strategy.
How to send Solana transactions without getLatestBlockhash results? Essentially, there are two options:
Use Persistent Transactions;
Retrieve a relatively new block hash using the following combination:
Using getSlot, it will retrieve a relatively new slot due to the rounding error required to reach consensus;
Use getBlock to retrieve the block for that slot, which contains the block hash.
Conclusion
The release of the SOL RPC container marks the completion of the ICP roadmap Helium milestone, which allows smart contracts on the Internet Computer to interact with the Solana blockchain. Check out the SOL RPC codebase and its examples to kickstart your smart contract journey:
github.com/dfinity/sol-rpc-canister
Reference
EVM RPC Blog Article:
ICP <> Ethereum: How ICP's EVM RPC Container Connects to the Network
ICP Roadmap: Chain Fusion Helium
internetcomputer.org/roadmap#Chain%20Fusion-Helium
Solenoid Milestone Blog Article:
Solenoid: The Decentralized Edge of the Internet Computer
Article on Schnorr and ECDSA Signatures:
Unlock Chain Fusion with Schnorr and ECDSA Signatures
IC Content You Care About
Technical Progress | Project Info | Global Events
Follow IC Binance Channel
Stay Updated