Let me make this clear. As a generalization you can think of the Solana world as a world dominated by accounts. A Solana program is, in fact, just an account that is marked as executable. From solana official document We read that there is an account:

A record in the Solana ledger that either holds data or is an executable program.

In Solana, there are in addition to data accounts and program accounts. original account which points to native programs on Solana. One of the most important is the system program. This program is important because each new account on Solana is by default owned by a system program.

To sum up our account knowledge, we can say that in an account:

1. an owner → it must be a program and is system program by default
2. a holder → this is the person who holds the private key to the account
3. can always be addressed by the public key
4. Can hold both data (if not executable) and SOL (solana native token)

This raises an important question. How do I transfer SOL to/from my account if I am not the owner of my account? On Solana, one can do while crediting the account, only the account owner can debit the account and change its data.

Solana achieves this in the following way:

1. The account holder must sign an instruction with his private key
2. Instruction is to be sent to the system program (which is the account owner and only one is allowed to debit the account and change his/her data)
3. The system program checks the private key against the account public key and if the check is OK, the transfer is authorized.

I hope this clarified the programs and accounts in Solana. Now we are ready to see some code.

If you are familiar with REST API, when you write a program on Solana chain you need to define which instructions your program would be able to process as they were the endpoints of your web-server.

A function signature typically takes the following arguments:

• Program ID → This is the public key of the currently executing program
• Accounts that the program can read and write during this transaction. The location of an account in the array reflects its meaning, for example, when an instruction transfers money the first account may be defined as the source and the second as the destination.
• Additional data specific to the function

In plain Rust code this translates to:

It’s important to note that Solana wants you to pass the functions to all accounts involved in the transaction. This allows Solana to optimize transaction throughput by parallelizing transactions involving different accounts.

In other words, the runtime can look at all incoming transactions in a program (and even across programs) and check whether the memory regions in the first argument of the transaction overlap. If they don’t, the runtime can run these transactions in parallel because they don’t conflict with each other. Even better, if the runtime sees that two transactions access overlapping memory regions but only do reads and no writes, it can even parallelize those transactions because they don’t conflict with each other!

For an example, let’s look at hello world example Provided by Solana. In this example, we want to store the time we greeted a specific account. Since the programs in Solana are stateless, we need to at least:

1. a hello world Executable program (aka program account) that can process our instruction
2. one or more greetings account (One for each account you want to congratulate). They would be non-executable programs (aka. data accounts) that could store the number of times they were greeted. Those accounts must be owned by the Helloworld program in order to make changes

Regarding bullet point 1, we can simply deploy our helloworld program using Solana CLI,

Regarding bullet point 2, we can create a Greeting account when it doesn’t exist before doing Hello and transfer the ownership to the Helloworld program (for full customer code check out) Here,

now process_instruction The Rust code should be far more clear. Let’s see:

Let’s dive into it:

1. We get the accepted account value from the list of accounts next_account_info use from solana
2. We check if the HelloWorld program ID is an owner for that account and the ability to make changes. If not we throw an error
3. If all is well:
   – We deserialise the account using borsh
   – We increment the counter inside the data property
   – We reorder the account with new data

As you may have noticed, the basic Solana code contains a lot of boilerplate (like paragraph numbering and deserialization, account verification…).
For this, anchor There is a framework that helps you build Solana programs with this and mainly focuses on the business logic of your program.

Now, you might be wondering why not start with an anchor instead of doing a plain solana 🙂 In general, I believe starting from scratch is always a good way to understand how to abstract over the top Can work and allows you to make conscious choices while developing. ,