ERC-7694: Solana Storage Router

Abstract

---

The following standard is an extension to the cross-chain storage router protocol introducing the storage router for Solana blockchain. With this specification, any Ethereum L1 contract can defer a call to Solana blockchain as part of its core functionality, provided that the client is equipped to handle Solana transactions. It was previously possible to defer write and storage operations to other Ethereum L1 contracts, L2 contracts and off-chain databases, and this document extends that functionality to include alternative L1 chains. The data stored on Solana must be translated to EIP-3668-compliant format by an appropriate HTTP gateway where it can be retrieved by generic Ethereum contracts. This standard allows Ethereum to utilise a broader range of cross-chain blockspaces.

Motivation

---

Cross-Chain Storage Router Protocol (CCIP-Store) introduced in EIP-7700, describes three external routers for routing storage to L1 contracts, L2s and databases. This document extends that specification by introducing a fourth storage router targeting Solana as the storage provider.

L2s and databases both have centralising catalysts in their stack. For L2s, this centralising agent is the shared security with Ethereum mainnet. In case of databases, the centralising agent is trivial; it is the physical server hosting the database. In light of this, a storage provider that relies on its own independent consensus mechanism is preferred. This specification instructs how the clients should treat storage calls made to the Solana router.

Solana is a low cost L1 solution that is supported alongside Ethereum by multiple wallet providers. There are several chain-agnostic protocols on Ethereum which could benefit from direct access to Solana blockspace; ENS is one such example where it can serve users of Solana via its chain-agnostic properties while also using Solana's own native storage. This development will encourage more cross-chain functionalities between Ethereum and Solana at core.

Specification

---

A Solana storage router StorageRoutedToSolana() requires the hex-encoded programId and the manager account on the Solana blockchain. programId is equivalent to a contract address on Solana while account is the manager wallet on Solana handling storage on behalf of msg.sender.

Since Solana natively uses base58 encoding in its virtual machine setup, programId values that are hex-encoded on EVM must be base58-decoded for usage on SVM. Clients implementing the Solana router must call the Solana programId using a Solana wallet that is connected to account using the base58-decoded (and casted to appropriate data type) calldata that it originally received.

In the above example, EVM-specific bytes32-type variables programId, account, node, key and value must all be converted to SVM-specific PubKey data type. The equivalent setValue() function in the Solana program is of the form

Since EVM and SVM have differing architectures, it is important to define precise data type castings from EVM to SVM. Some pre-existing custom but popular data types in SVM already equate to common EVM data types such as PubKey and bytes32 respectively. This specification requires the following implementation of bijective EVM to SVM type casting:

EVM	SVM
uint8	u8
uint16	u16
uint32	u32
uint64	u64
uint128	u128
uint256	u256†
bytes1	bytes: [u8; 1]
bytes2	bytes: [u8; 2]
bytes4	bytes: [u8; 4]
bytes8	bytes: [u8; 8]
bytes16	bytes: [u8; 16]
bytes32	PubKey
bytes	bytes: Vec<u8>
string	String
address	bytes: [u8; 20]

† u256 is not available natively in SVM but is routinely implemented via u256 crate in Rust

Using this strategy, most - if not all - current use-cases of StorageRoutedToSolana() are accounted for.

Finally, in order to read the cross-chain data stored on Solana in an arbitrary Ethereum contract, it must be translated back into EVM tongue by an EIP-3668-compliant HTTP gateway. The arguments for a generic call to the gateway URL must be specified in the /-delimited nested format as described in EIP-7700. The core of such a gateway must follow

In the above example, the generic getValue() function in the Solana program is of the form

Rationale

---

StorageRoutedToSolana() works in a similar fashion to StorageRoutedToL2() in CCIP-Store in the sense that the client needs to be pointed to a certain contract on another chain by the revert event. Other than that, the only technical difference is casting between EVM and SVM data types.

Backwards Compatibility

---

None.

Security Considerations

---

None.

Copyright

---

Copyright and related rights waived via CC0.