The Indexer is a critical component of Neon’s functionality. Understanding it is key to comprehending the way the Neon EVM interacts with the Solana network, as it is responsible for matching Solana transactions to Neon transactions. This introduction will give you a high-level overview of Neon’s Indexer.
What is the Indexer?
Neon’s Indexer is part of Neon’s proxy architecture, which is a multi-process program. The Indexer’s purpose is to cancel ongoing iterative transactions sent from blocked Neon accounts, as well as to save the Neon EVM transaction history from all proxies (by maintaining a database of all Neon EVM transactions).
How It Works
The Indexer runs by executing a constant cycle of sequential operations. The steps of this cycle are as follows:
- Step 1: Fetch Solana Transactions
In this stage, the Indexer fetches all new Solana transaction signatures that involve the Neon EVM, and requests the transaction details based on these signatures.
- Step 2: Process Transactions
The Indexer then proceeds to process all the transactions it fetched, starting with the oldest and proceeding in chronological order. The transactions that involve the Neon EVM are singled out for more comprehensive processing down the line. Solana transactions consist of three fields: data, accounts, and destination contract address.
- Step 3: Rebuild Neon Transactions
Based on the information the Indexer received from these Solana transactions, it will begin to construct Neon transactions that mirror the activity on Solana. These transactions are analyzed to determine what kind of request was made to the Neon EVM contract. There are three types of requests that the Indexer is interested in:
- Neon account creation
- Non-iterative transactions (executed in one Neon transaction)
- Iterative transactions
Iterative Transactions
If an iterative transaction is required, it can be constructed based either on the data from the accounts involved, or based on the Solana transaction data alone if it is under 1280 bytes. In the case that the account data is used, the Neon transaction is written into a special account (used only for this purpose), and this information is subsequently sent to the Neon EVM for iterative processing.
In this case, the Indexer keeps track of transactions that record data into an account and, in cases where one Neon write transaction requires multiple Solana transactions, the correct order that the instructions should be implemented on Solana. This data is then used to help process the next iterative transaction involving that account.
If an iterative transaction is not marked as “completed” but all the accounts involved with it are blocked, the Indexer will cancel this transaction.
Non-Iterative Transactions
If a non-iterative transaction is required, all the necessary information can be extracted from the Solana transaction. This information includes the accounts involved, changes in the balances of these accounts, and the execution result (e.g. “success” or “error” and how much gas was used). The Indexer will need to trace future transactions with the same data to add it to the same Neon transaction.
- Step 4: Prepare Data for the Neon Proxy
Once the Neon transactions have been built based on the Solana transaction data, the resulting data and logs are stored in a database. This database can then be queried by the proxy to get information such as contract code, transaction details, logs, and more. The proxy uses this to process requests it receives from the client.
Summary
Neon’s Indexer, by fetching and processing Solana transactions for the Neon EVM, is crucial to the way the Neon EVM interacts with Solana. It cancels those transactions that are “stuck” in an incomplete state with all their accounts blocked. It also keeps a database of all the Neon EVM transactions it has processed. In doing so, the Indexer allows the proxy to provide important transaction information to the proxy users.
