Individually inject polkadot api and ethers api instead of single api in substrate frontier project

[Niraj-Kamdar]

Prerequisites

• [x] Are you running the latest version(s)?
• [x] Have you searched the documentation for your issue?
• [x] Did you search for an existing issue or pull request?

Description

In Substrate Frontier projects, we need the ability to individually inject both the Polkadot API and the Ethers.js API instead of a single api object. This enhancement would allow developers to access both Substrate-specific and EVM-specific functionalities within the same mapping handlers, which is essential for indexing data on a Frontier-based chain that supports both Substrate modules and EVM contracts.

Details

These details can help to reproduce the environment where the issue is occurring:

Local Environment:

$ subql version
@subql/cli: 5.1.1

Query Version: 5.1.1

Indexer Version: 5.1.1

Network Details:

• Network: Frontier-based Substrate chain (e.g., Moonbeam, Astar)
• Block Height: Occurs at any block height
• Dictionary Endpoint: Not used

Steps to Reproduce

1. Initialize a SubQuery Project: Create a new SubQuery project targeting a Frontier-based Substrate chain that supports EVM contracts.

2. Attempt to Use Both APIs: In your mapping handlers (e.g., mappingHandlers.ts), try to use both the Polkadot.js API and the Ethers.js API:

   export async function handleBlock(block: SubstrateBlock): Promise<void> {
    // Attempt to use Substrate API
    const blockNumber = await api.rpc.chain.getHeader();
   
    // Attempt to use Ethers.js API
    const provider = api; // Assuming 'api' is an Ethers.js provider
    const balance = await provider.getBalance(someAddress);
   }

3. Observe the Issue: You'll notice that the api object cannot be both a Polkadot.js API and an Ethers.js provider simultaneously. This limitation prevents access to both Substrate and EVM functionalities within the same handler.

Expected Behavior

We expect to have both APIs injected separately into the mapping handlers, such as:

• polkadotApi: An instance of the Polkadot.js API for interacting with Substrate modules.
• ethersApi: An instance of the Ethers.js provider for interacting with EVM contracts.

This separation allows us to:

• Query Substrate-specific data using polkadotApi, such as storage queries and chain state.
• Interact with EVM contracts using ethersApi, such as calling contract methods and querying balances.

Example Usage:

export async function handleBlock(block: SubstrateBlock, { polkadotApi, ethersApi }): Promise<void> {
  // Use Polkadot.js API
  const blockNumber = await polkadotApi.rpc.chain.getHeader();

  // Use Ethers.js API
  const balance = await ethersApi.getBalance(someAddress);
}

Actual Behavior

Currently, only a single api object is injected into the mapping handlers, which is either:

• A Polkadot.js API instance for Substrate chains.
• An Ethers.js provider for EVM chains.

This setup forces developers to choose between Substrate and EVM functionalities, which is not practical for Frontier-based chains that support both.

Any Other Information

References from Documentation:

• Querying Contracts (EVM Chains):

  We globally provide an api object that implements an Ethers.js Provider. This will allow querying contract state at the current block height being indexed.

  Example:

  const erc20 = Erc20__factory.connect(contractAddress, api);
  const balance = await erc20.balanceOf(address);

• Query States (Polkadot Chains):

  We have exposed some of the @polkadot/api interfaces to increase capabilities.

  Example:

  const data = await api.query.system.account(accountId);

Issue Summary:

In Frontier-based Substrate chains, both Substrate modules and EVM contracts are first-class citizens. Developers need access to both the Polkadot.js API and the Ethers.js API within the same mapping handlers to fully leverage the chain's capabilities.

Proposed Solution:

• Inject Both APIs Separately: Modify the SubQuery runtime to inject both polkadotApi and ethersApi into the context of mapping handlers.

• Update Type Definitions: Ensure that TypeScript definitions are updated to recognize both APIs, allowing for proper type checking and IntelliSense support.

• Backward Compatibility: Maintain backward compatibility by keeping the existing api object for projects that target only Substrate or EVM chains.

Benefits:

• Enhanced Functionality: Enables comprehensive data indexing by accessing both Substrate storage and EVM contract data.

• Developer Experience: Simplifies the development process by providing clear and separate APIs for different functionalities.

• Ecosystem Growth: Encourages more projects to adopt SubQuery for indexing on Frontier-based chains.

Thank you for considering this feature request. Implementing this enhancement will significantly improve the developer experience and capabilities when working with Frontier-based Substrate projects.

[stwiname]

Hi @Niraj-Kamdar

This is already possible. You can use the FrontierEthProvider which implements the ethers provider interface.

Example:

const provider = new FrontierEthProvider();
const erc20 = Erc20__factory.connect(contractAddress, provider);
const balance = await erc20.balanceOf(address);