Solana Walkthrough - Part 2

The original Walkthrough

and my experience with it

0. Preamble

Solana Walkthrough - Preamble

Walkthrough[https://paulx.dev/blog/2021/01/14/programming-on-solana-an-introduction/] -@paulx has a walkthrough time to dive in... so let’s try it out Let’s start off with installing everything locally * Installing the CLI tools [https://docs.solana.com/cli/install-solana-cli-tools…

8teapi8teapi

1. Part 1

Solana Walkthrough - Part 1

The original Walkthrough[https://paulx.dev/blog/2021/01/14/programming-on-solana-an-introduction/] Any my experience with it Solana Walkthrough - PreambleWalkthrough[https://paulx.dev/blog/2021/01/14/programming-on-solana-an-introduction/…

8teapi8teapi

Continuing onto Part 2 - The Token Program

Documentation - As far as I can tell the Token Program is one of a small number of primitives in the Solana Program Library provided by the dev team. These are the critical use cases that they had to cover right out of the box.

The Token Program provides a framework for a user to issue tokens.  Tokens may be fungible or non-fungible, you just declare the mint 1 token and disable future minting and voila an NFT.

The token account, which is not the same as the account (God, this is going to be confusing), holds the tokens. Each token account has an owner. The account owner is a program, the token account owner is a user.

Token account has the following data attributes, which are solely user space information

$ spl-token account-info 559u4Tdr9umKwft3yHMsnAxohhzkFnUBPAFtibwuZD9z

Address: 7KqpRwzkkeweW5jQoETyLzhvs9rcCj9dVQ1MnzudirsM
Balance: 1
Mint: 559u4Tdr9umKwft3yHMsnAxohhzkFnUBPAFtibwuZD9z
Owner: vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg
State: Initialized
Delegation: (not set)
Close authority: (not set)

The token owner address is going to the user's main account. The user has to sign any transactions.

The mint, is the type of token basically. There is a mint account for each token that holds the token's metadata such as supply.

Interesting.. and as a result of the above, I actually understand the below now

The token account is basically a bag. The bag can be filled with only one type of token. The bag also references the central bank for that token (the mint). The bag knows who it's owner is.

You can't own a token directly, you can only own the bag.

The escrow program needs to create a temporary bag, because we're going to provisionally approve the transfer from one end, while waiting for the other end to complete.

Also Program Derived Address (PDAs), which I guess are Addresses generated by Programs...

If the caller does not mark the account writable in their calling code but the program attempts to write to it, the transaction will fail. This is basically a constraint that enables parallelization.  

The escrow comments below:

    /// 0. `[signer]` The account of the person initializing the escrow
    /// 1. `[writable]` Temporary token account that should be created prior to this instruction and owned by the initializer
    /// 2. `[]` The initializer's token account for the token they will receive should the trade go through
    /// 3. `[writable]` The escrow account, it will hold all necessary info about the trade.
    /// 4. `[]` The rent sysvar
    /// 5. `[]` The token program

Interestingly the rent amount is a sysvar, which means it depends on the cluster.. So many presumably different clusters will have different policies, kinda like Minecraft

Solana has sysvars that are parameters of the Solana cluster you are on. These sysvars can be accessed through accounts and store parameters such as what the current fee or rent is