2/ Calling between programs is achieved by one program invoking an instruction of the other.
Here's how that looks in practice.
The first arg is the instruction to be invoked, and the second arg is the array of accounts required by that instruction.
3/ Notably, if an account was specified as writeable and/or a signer, those privileges will be granted to the called program.
E.g. if associated_token_account_info can be written to by the current program, then the initialize_account instruction will also be able to write to it.
4/ There's another function you'll encounter when working with CPIs: invoke_signed.
It's only necessary when working with PDAs, and takes one more argument: signers_seeds.
Each item is an array of seeds for some PDA.
Including the seeds for a PDA account makes it a signer.
5/ For example, here's how it would look if you wanted to sign the instruction with two PDA accounts.
6/ Why are CPIs useful?
Remember, one of the main points of web3 is composability. With CPIs, the Solana programs you write can leverage all the programs that have already been written.
For example, a common use case is calling into the SPL token program.
That's it! Not too complicated right π
Next time we'll look at how CPIs work when using Anchor.
Btw, if you were confused about the PDA part of this thread, this might be useful
There are three main reasons why people say Solana is centralized:
1. Expensive to run a validator 2. Token distribution 3. Only one blockchain software client
Let's take a look at each of these reasons π
1/ IMO it doesn't matter how much it costs to be a validatorβit matters how many validators there actually are, and what the Nakamoto coefficient is.
Turns out Solana's Nakamoto coefficient is pretty high (19 validators required to halt the network).
Here's a diagram that shows all the different parts of a Solana transaction.
More details below π
1/ Each Solana transaction contains a message, and the first part of each message is its header.
The header is simple, it just contains the numbers described in the diagram.
2/ The next part of the transaction message is an array of accounts. They are ordered based on whether they require a signature and whether they are writable.
This array also contains the addresses of the programs used by the instructions.
1/ Here's a thread of all the Solana threads I've written (a thread of threads), plus some great threads/tweets by other folks. I'll try to keep adding onto this in the future.
First, 11 resources to get started with Solana development
Here's my smooth brained understanding of Solana and rollups
1/ First off, a rollup is a L2 scaling solution. With rollups, a bunch of transactions are executed off-chain, and their data is posted on L1. This increases throughput, because instead of L1 processing 10 individual txs, it can process 1 "rolled-up" tx.
2/ So is Solana planning on having rollups on top of its L1? No β
Just spent the past hour reading about Solana and rollups on Twitter. 99% of it went over my head but it was interesting π. Links to some of the more interesting threads I read below...