SVM Chain Identifier

[kespinola]

Context

The discussion revolves around the need for a chain ID in the transaction format for Solana chains to enhance security and prevent phishing attacks. This is similar to how EVM chains handle chain IDs, which are essential for differentiating between different blockchain networks and preventing replay attacks. In Solana's case, the genesis PoH (Proof of History) hash can be used as the chain ID.

Key Points

1. Chain ID in Transaction Format:

   • A chain ID embedded in the transaction format is crucial to ensure that transactions are executed on the intended network, preventing replay attacks and enhancing security.

2. User-Controlled Custom Chains:

   • Users should have the ability to add custom chains to their wallets without needing permission from the wallet provider. This improves user autonomy and flexibility.

3. Phishing Attack Prevention:

   • A chain ID helps prevent phishing attacks where malicious actors trick users into signing transactions on a fake network that actually targets a mainnet or other critical network.

Recommendations

1. Adopt Chain ID Using Genesis PoH Hash

• Chain ID Specification: Use the genesis PoH hash as the chain ID, which will be included in the transaction data. Each chain will have a unique PoH hash that differentiates it from others.
• Unique Assignment: Ensure each chain ID (PoH hash) is unique and assigned based on the genesis block creation.

2. Chain ID Management

• Central Registry: Establish a central registry for chain IDs, where each chain’s genesis PoH hash, name, and RPC URL are registered. This registry should be publicly accessible and maintained by a trusted organization or consortium.
• Decentralized List Hosting: Use a decentralized approach to host the list of chain IDs, ensuring that no single entity has control over it. Options include distributed file systems like IPFS or blockchain-based solutions.

3. Transaction Format Update

• Include Chain ID: Update the Solana transaction format to include the chain ID (genesis PoH hash). This ensures that every transaction is tagged with the appropriate network identifier.
• Backward Compatibility: Implement the chain ID inclusion in a backward-compatible manner to ensure that existing tools and applications can adapt gradually.

4. Wallet and RPC Support

• Wallet Integration: Ensure that wallets can handle custom chain IDs seamlessly. Users should be able to add custom chains and view/send/receive native tokens and transaction history.
• RPC Node Configuration: Update RPC node configurations to recognize and enforce chain IDs, ensuring that transactions are validated against the correct network.

5. Security Measures

• User Warnings: Implement user warnings and confirmations when adding or switching to a custom chain. Inform users about the risks of phishing attacks and the importance of verifying chain IDs.
• Verification Mechanism: Develop mechanisms to verify the legitimacy of custom chains before allowing them to be added to wallets. This could involve community reviews, automated checks, and reputation systems.

6. Automatic Registry Verification

• Automatic Registry: Enable an automatic registry system that takes the chain name, RPC URL, and genesis PoH hash to confirm its correctness. This can be done through:
  • Automated Checks: When a new chain is registered, automated systems verify the genesis PoH hash against the provided RPC URL.
  • Community Reviews: Community members can review and confirm the correctness of new entries to prevent malicious chains from being added.

[kespinola]

Topic by armaniferrante Proposed solution by @irvinxyz in Zuma SVM TG.

[kespinola]

Resources from EVM:

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md https://github.com/ethereum-lists/chains

[kespinola]

https://github.com/anza-xyz/wallet-standard/issues/9