Overview — Cryptography & Keys

The book keeps circling one question: how do you build a single global state machine that runs at hardware speed without falling apart? Part 1 — The Account Model answered a piece of it: global state is one flat map, Pubkey → Account, where every wallet, token balance, and program is an entry keyed by a 32-byte public key. That part told you the map exists. It did not tell you what those 32 bytes actually are, where they come from, or — crucially — who is allowed to sign for the account they name.

This part answers exactly that. It is short, foundational, and mostly cryptography: the mechanics of identity and authorization on a chain that has no accounts registry. There is no sign-up, no “create account” call, no username table anywhere. So where does identity come from? The whole answer fits in one sentence, and it is the throughline of this part.

The thesis, stated up front

On Solana, identity and authorization come entirely from ed25519 keypairs plus base58 encoding — nothing else.

There is no account database that maps names to people. A keypair — a private key you keep secret and a public key you can share — is an identity. The public key, encoded as a base58 string, is an address. A signature made with the private key is the only proof the runtime accepts that “the holder of this address authorized this transaction.” That is the entire trust model. No passwords, no sessions, no registry — just the math of ed25519 and 32 bytes of public key sitting in the flat map.

   Where identity comes from — the whole part in one picture
   ──────────────────────────────────────────────────────────

   private key (32 bytes, SECRET)
        │  ed25519
        ▼
   public key (32 bytes)  ──base58──►  address string  "9WzD…4bXk"
        │                                    │
        │  sign(msg)                         │  names an entry in
        ▼                                    ▼
   signature (64 bytes)  ──verify──►   Pubkey → Account   (Part 1's flat map)
        │
        └─ the ONLY proof the runtime accepts that the address's holder authorized this

The surprise to flag early: the address IS the public key

If your intuition comes from Bitcoin, name this now, because it is the one thing most likely to trip you. On Bitcoin, an address is not a public key — it is the end of a hash pipeline. A public key is run through SHA-256, then RIPEMD-160, then version bytes and a checksum, then Base58Check (or bech32) encoding, and that string is your address. The raw public key is hidden until the moment you spend, and the address you hand out is a hash of it.

Solana throws that pipeline away.

   Bitcoin: address is a HASH of the key            Solana: address IS the key
   ─────────────────────────────────────            ──────────────────────────
   pubkey ─► SHA-256 ─► RIPEMD-160 ─► +version       pubkey (32 bytes)
          ─► +checksum ─► Base58Check ─► address             │ base58 encode
   (the address hides the raw public key)                    ▼
                                                       address string
                                              (the address IS the raw public key, re-encoded)

On Solana there is no hashing between the public key and the address. A Solana address is the 32-byte ed25519 public key itself, written in base58 for humans. Decode the base58 and you are holding the literal public key the runtime will verify signatures against. That is why this part can teach “keys” and “addresses” almost as one topic: for an ordinary wallet, they are the same 32 bytes. Base58 is just a display format; it adds no cryptography.

This has real consequences we unpack across the part — most importantly, it is why Program Derived Addresses need a special trick. If an address is just a public key, then a program that wants its own address has a problem: it has no keypair. The resolution — addresses deliberately chosen to have no private key — is the payoff this part builds toward.

The thread

What does this part force you to understand? That on a registry-free chain, every act of identity and authorization reduces to keys and signatures. An address is a public key (base58-encoded). Owning an account means holding the matching private key. Authorizing a transaction means producing an ed25519 signature the network can verify against that public key. Once you internalize this, two later ideas stop being magic: a wallet is just a keypair, and a PDA is just an address with the private key deliberately removed so a program can be its authority instead of a human. The rest of the book — transactions, programs, cross-program invocation — assumes all of this without re-explaining it.

Roadmap for this part

Read these in order. Each page forces one idea, and each idea is a link in the chain from keypair to derivation.

#	Page	What it adds	The idea it forces
2	Ed25519 Keypairs	what a keypair actually is: a secret scalar and a curve point	identity on Solana is a keypair, not a database row
3	Addresses ARE Public Keys (Base58)	the 32-byte public key and its base58 encoding, with no hash pipeline	an address is the public key — base58 is display, not cryptography
4	Message Signing & Verification	how a signature over a message proves authorization	a signature is the only proof of authority the runtime accepts
5	Program Derived Addresses (Off-Curve Addresses)	addresses deliberately chosen to have no private key	a program can own an address by ensuring no one holds its key
6	Deriving a PDA — Seeds & the Bump	the exact derivation: seeds, program id, and the bump search	how an off-curve address is computed deterministically
900	Revision — Cryptography & Keys	the whole part compressed to what you must retain	the minimum you carry into transactions and programs

By the end you will be able to take a base58 string like 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM, say precisely what those bytes are, whether they name a wallet or a PDA, and who — a human with a key or a program with no key — is allowed to sign for it.

The first job is to make the keypair concrete: what a private key and a public key actually are, and why ed25519 in particular. Start with Ed25519 Keypairs.

A note on the companion crate

The book’s miniature runtime, solmini, keeps a 32-byte Pubkey type but does not implement real ed25519 — it derives demo keys by hashing a label, purely to keep tests readable:

/// A 32-byte public key — the address of an account or a program.
///
/// Real Solana keys are ed25519 public keys; here we derive a deterministic key
/// from a label by hashing it, which is all the demo needs and keeps tests
/// readable (`Pubkey::from_seed("alice")`).
pub struct Pubkey([u8; 32]);

That is a deliberate simplification: the runtime cares only that a key is 32 bytes and comparable, not how it was generated. This part is where we replace that hand-wave with the real thing — genuine ed25519 keypairs, real signatures, and the actual off-curve rule that makes PDAs work. When a later page shows Pubkey::find_program_address, it is doing on real curve points what from_seed only pretended to do.

Check your understanding

1. Solana has no accounts registry — no table mapping names to people. So where does identity come from, and what three things (per the thesis) is it built from?
2. State the single biggest surprise for someone coming from Bitcoin. What does Bitcoin do between a public key and an address that Solana does not do?
3. For an ordinary wallet, how many distinct 32-byte values are there — one for the “address” and one for the “public key,” or the same one? What is base58’s job, exactly?
4. This part connects back to Part 1’s flat Pubkey → Account map. What did Part 1 leave unexplained about those keys that this part fills in?
5. Preview the payoff: what is a Program Derived Address, in one sentence, and why does “an address is just a public key” make PDAs need a special construction?

Show answers

1. Identity comes entirely from cryptographic keypairs — there is no database to look anyone up in. It is built from three things: an ed25519 keypair (a secret private key + a public key), base58 encoding (to turn the public key into a human-readable address string), and signatures (the only proof the runtime accepts that the key’s holder authorized an action). Nothing else — no passwords, sessions, or registry.
2. On Solana the address is the public key, re-encoded in base58 with no hashing. Bitcoin runs the public key through a hash pipeline — SHA-256 then RIPEMD-160, plus version bytes, checksum, and Base58Check — so a Bitcoin address is a hash of the key and hides the raw key until you spend. Solana skips that pipeline entirely.
3. The same 32 bytes. For a wallet, the address and the public key are one value; there is no separate “address” derived from the key. Base58’s only job is display/encoding — turning those 32 raw bytes into a copy-pasteable string. It adds no cryptography and no hashing.
4. Part 1 established that global state is a flat map keyed by 32-byte Pubkeys, but it did not say what those bytes are, where they come from, or who may sign for the account they name. This part fills that in: the bytes are an ed25519 public key, and the right to modify a keypair-owned account is proven by an ed25519 signature from the matching private key.
5. A PDA is an address deliberately constructed to have no private key, so a program (not a human) can be its authority. Because an ordinary Solana address is a public key — and a program has no keypair — a program cannot just “have an address” the normal way; the PDA construction gives it one by choosing an address that lies off the ed25519 curve, where no private key can exist.