Most new developers find it difficult to get started with building on Solana because they find the programming model unintuitive. However, it is far from unintuitive once you understand it from the first principles. My goal at the end of this article is to get you to the aha moment I had when I finally made sense of it.

Accounts Model

Before we dive into the accounts model and understand how things work in Solana, let’s work with something even simpler.

Rust will allocate 8 bytes of memory on the stack and return a reference to its address.

Every time your program has to store something in its main memory, the run time takes the exact size requirement, finds a location and returns its address to you. So that you can manipulate the contents of address the way you want.

This works great as long as the program is running, if you were to restart or run it again, the state of the program (i.e gm count) gets reset.

In order to prevent this we can replicate the content of the memory and store it to disk and restore the state upon invocation.

Our setup works well when all we have to do is support one user. For multiple users, perhaps we could use a hash-map to keep track of all the users and their gms.

We could do the same load from disk as before, however, we would be loading all users and their counters into the application memory, this can be problematic for the following reasons

What can we do to allow concurrent access while maintaining persistence? Perhaps instead of snapshotting the entire application state, we could isolate the snapshots to a user and their associated data.

What we have done here is to take out the hash function and use it to dump the counter to a file instead of a hash map. Now, that the user data is partitioned and isolated to a single file, we could invoke the&nbsp;gm&nbsp;function against a particular&nbsp;user_id&nbsp;without affecting the global state, a nice benefit of this is that the runtime can access multiple&nbsp;user_id's&nbsp;in parallel. What we have essentially done here is to externalize the state and decouple it from our code.

If a client wants to query the number of&nbsp;gm&nbsp;s a user has received, they can simply look it up from the account file we just created for the user. However, the data is saved as raw bytes, in order to make sense of it, we would need to know the structure of the data before it was serialized.

This decoupling of&nbsp;<i><b>state and code</b></i>&nbsp;is one of Solana’s core features and how we create smart contracts or programs in Solana is dictated by its accounts model. Watch this space for how this intuition actually translates and builds into Solana's accounts model.

fe8382fee70e6df4c74ec9aab9d9cd592599242a864cf1c6fb7831f8477b824d