Decoding Solana data accounts

For the transaction output of the solana confirm command we can read quite a good context from the logMessages that often shows the Instruction name and informs what happens. But let’s take a look only on the base info and the call data here. We can see there is used one instruction and we can check more about accounts as well.

When examining the transaction output of the solana confirm command, we can extract valuable information from the logMessages. The log messages often provide insightful details, such as the Instruction name However, for our current purpose, let’s focus solely on call data. We can observe that a single instruction was utilized, and we can delve deeper into the involved accounts.

Let’s examine the data in the same format of uint8 array as we did for an account above.

We are aware that the Anchor program employs the first 8 bytes as a discriminator, indicated here as [163, 217, 65, 81, 53, 230, 29, 28]. Unlike Ethereum, Solana follows a single entrypoint approach for programs. In this paradigm, the program itself assumes the responsibility of determining which operation or function should be executed. This is where the discriminator plays a crucial role. These 8 bytes serve as a defining factor, allowing the deployed program to select the appropriate function for execution. The Anchor discriminator is calculated as a hash from the source from the name of the operation /function.

As we have the source code of the program we can use again the anchor expand command to find out that the operation that will be executed.

Now, let’s examine the accounts that are involved. From the output of the solana confirm call it appears that the account at index 3 is used as the program address, while accounts at indexes 2 and 1, in that particular order, are considered as instruction input accounts. From inspecting the accountKeys the keys are indexed starting from 0. It’s worth noting that the public key at index 0 is responsible for paying the transaction fee, i.e., it’s the feePayer. By examining the values, we can determine that sa3HiPEaDZk5JyU1CCmmRbcWnBc9U4TzHq42RWVUNQS corresponds to the program ID, and the two accounts provided are DabBrrPf3JcNgKqcYNhn3tVcfPwDpsQ6HdAifNWi1ebJ and HJ6DPqQhAYRw8YyEuVXV8mwzzNAexxEYVC3aQutWxWn8, listed in that order.

With the code at hand we can examine the PrintAdmin instruction source code.

We can read that the first account address passed in the instruction, the DabBrrPf3JcNgKqcYNhn3tVcfPwDpsQ6HdAifNWi1ebJ, is used as storage data account (pub simple_admin_account: Account<'info, SimpleAccount>). The second account address HJ6DPqQhAYRw8YyEuVXV8mwzzNAexxEYVC3aQutWxWn8 is the admin wallet address and we recognize that this key has to sign the transaction. Only when the transaction is signed by this key the processing is allowed (` pub admin: Signer<'info>`).

Now what about the call data? We already know that the first 8 bytes is the discriminator of the operation. The rest is a message PrintAdminParams#message. The message is a string. As it’s Solana Rust We know it will be the UTF-8 string. In assistance of the python scripts we can get the message in a readable form.

And we can see that the transaction log should contain the message hello3 (i.e., msg!(…​) Solana Rust macro). Let’s confirm it in the transaction listing.

One of the purposes to change the account data could be loading accounts for tests. One may want to start the solana test validator at localhost and process actions that are not possible at mainnet for testing purposes. Let’s say we want to mint a MNDE token that was minted with max amount and there is no more mint authority. We can load the account from the mainnet, change the data interpretation and then pass the changed account at the test validator start-up.

We are interested in data of that account. The interpretation of the data can be read from the source code or this Sec3 article Understanding SPL Token Mint.

We can see the account first bytes belongs to the mint authority mint_authority: COption<Pubkey> which is the part we want to change. The COption is coded as 4 bytes where [1,0,0,0] means to be setup and then following 32 bytes of Publickey. So let’s get it all together and load the solana-test-validator.

In the case of our test program, "SimpleAdmin," let’s search for all admin accounts (SimpleAccount) that have been executed three times. To achieve this, we need to search for Solana accounts that are owned by the "simple-admin" program deployed at devnet at sa3HiPEaDZk5JyU1CCmmRbcWnBc9U4TzHq42RWVUNQS where it has got data of print_call_count field equal to 3.

To accomplish this, we will make a call to the devnet RPC server (assuming we have already created an account instance there). For this example, we only need to determine the number of accounts that meet the criteria (print_call_count equal to 3). We do not need to download the entire program data. Hence, we set the dataSize parameter to 0.

Based on the provided filter criteria, we know that the data for each "SimpleAccount" consists of 8 bytes for the Anchor discriminator, followed by 32 bytes for the public key, and finally 8 bytes for the counter we want to match. The offset value we use is 40 (calculated as 8 + 32). To specify the data to match, we pass the base58 format of the byte array [3,0,0,0,0,0,0,0] (u64), which is represented as W723RTUpoZ.

You can check another example of setting up the filters of the the Solana RPC HTTP call getProgramAccounts at my response at the Solana Stack Exchange about bpf_loader_upgradeable data structures.

We talked about a potential way how to examine manually binary data structure of the Solana accounts and transactions call data. Despite it’s handy to check the account this way in general it’s tedious and unproductive. Toolings around Solana makes this just easier.

When we talk about the borsh formatted accounts (which are mostly those written in Anchor) there is a site https://borsh.m2.xyz to help. It helps to decode the account when we understand its structure. Similar as we did above manually with python/bash scripts we can just click through this web. Here is example for examined DabBrrPf3JcNgKqcYNhn3tVcfPwDpsQ6HdAifNWi1ebJ account. We fill-in the field types and size and offset is calculated for us.

A user-friendly tool for constructing transactions can be found at https://bettercallsol.dev/. This tool allows you to easily create transactions by interacting with various parameters through a graphical interface. Once you have defined the transaction, you have the option to run it, simulate it, or pass it to integrated systems for further processing. For more detailed information, you can refer to the blog post titled Solana Transactions with Better Call Sol.

In the context of this article, I attempted to define a transaction for the "Simple Admin" contract, specifically for the "PrintAdmin" operation. You can view the form and its parameters in the accompanying screenshot.

The most versatile approach is to have an IDL definition that can be interpreted by tooling, providing us with a dynamic understanding of the underlying binary structure. This allows us to gain insights into account names and interpret transactions and accounts within blockchain explorers. The aforementioned UI tool also utilizes IDL to offer information about account names.

When developing a program using the Anchor framework, the IDL is automatically generated. However, for non-Anchor programs, the Solita framework provided by the Metaplex Foundation can be utilized. There is an ongoing discussion about establishing a standardized way for IDL in Solana on the Solana forum.

For the benefit of Anchor IDL data interpretation, the program has to be published with IDL on chain. When one does it it can be seen in https://explorer.solana.com/ down in the box Anchor Program IDL.

For our examined Simple Admin contract the IDL can be seen in the Explorer and the Typescript format is published next to the contract at GitHub.

The Explorer makes it easy to access transaction details in a human-readable format. For example, you can observe the transaction with the id 55E5mPX87Ms55chvKdGUg2XCGrJ1Qp4Pw7ER4z4fCgSqtXQ3JhZGXP7mpohTxPEm8S87Q5PNW7x7MSqx9GDATMiF or the SimpleAccount DabBrrPf3JcNgKqcYNhn3tVcfPwDpsQ6HdAifNWi1ebJ.

Other Solana blockchain inspectors knows to interpret IDL data in the similar way. You can see the similar at Solana.fm for example.