Add doc content and feedback (#13563)

docs/src/developing/programming-model/transactions.md

@@ -7,8 +7,81 @@ submitted to the cluster. The Solana runtime will execute a program to process
 each of the [instructions](terminology.md#instruction) contained in the
 transaction, in order, and atomically.
 
-See [Anatomy of a Transaction](transaction.md) for more information about how a
-transaction is encoded.
+## Anatomy of a Transaction
+
+This section covers the binary format of a transaction.
+
+### Transaction Format
+
+A transaction contains a [compact-array](#compact-array-format) of signatures,
+followed by a [message](#message-format). Each item in the signatures array is
+a [digital signature](#signature-format) of the given message. The Solana
+runtime verifies that the number of signatures matches the number in the first
+8 bits of the [message header](#message-header-format). It also verifies that
+each signature was signed by the private key corresponding to the public key at
+the same index in the message's account addresses array.
+
+#### Signature Format
+
+Each digital signature is in the ed25519 binary format and consumes 64 bytes.
+
+### Message Format
+
+A message contains a [header](#message-header-format), followed by a
+compact-array of [account addresses](#account-addresses-format), followed by a
+recent [blockhash](#blockhash-format), followed by a compact-array of
+[instructions](#instruction-format).
+
+#### Message Header Format
+
+The message header contains three unsigned 8-bit values. The first value is the
+number of required signatures in the containing transaction. The second value
+is the number of those corresponding account addresses that are read-only. The
+third value in the message header is the number of read-only account addresses
+not requiring signatures.
+
+#### Account Addresses Format
+
+The addresses that require signatures appear at the beginning of the account
+address array, with addresses requesting write access first and read-only
+accounts following. The addresses that do not require signatures follow the
+addresses that do, again with read-write accounts first and read-only accounts
+following.
+
+#### Blockhash Format
+
+A blockhash contains a 32-byte SHA-256 hash. It is used to indicate when a
+client last observed the ledger. Validators will reject transactions when the
+blockhash is too old.
+
+### Instruction Format
+
+An instruction contains a program id index, followed by a compact-array of
+account address indexes, followed by a compact-array of opaque 8-bit data. The
+program id index is used to identify an on-chain program that can interpret the
+opaque data. The program id index is an unsigned 8-bit index to an account
+address in the message's array of account addresses. The account address
+indexes are each an unsigned 8-bit index into that same array.
+
+### Compact-Array Format
+
+A compact-array is serialized as the array length, followed by each array item.
+The array length is a special multi-byte encoding called compact-u16.
+
+#### Compact-u16 Format
+
+A compact-u16 is a multi-byte encoding of 16 bits. The first byte contains the
+lower 7 bits of the value in its lower 7 bits. If the value is above 0x7f, the
+high bit is set and the next 7 bits of the value are placed into the lower 7
+bits of a second byte. If the value is above 0x3fff, the high bit is set and
+the remaining 2 bits of the value are placed into the lower 2 bits of a third
+byte.
+
+### Account Address Format
+
+An account address is 32-bytes of arbitrary data. When the address requires a
+digital signature, the runtime interprets it as the public key of an ed25519
+keypair.
 
 ## Instructions
 
@@ -53,14 +126,22 @@ Which can be found here:
 
 https://github.com/solana-labs/solana/blob/6606590b8132e56dab9e60b3f7d20ba7412a736c/sdk/program/src/system_instruction.rs#L220
 
-### Program ID
+### Program Id
 
 The instruction's [program id](terminology.md#program-id) specifies which
-program will process this instruction. The program's account data contains
-information about how the runtime should execute the program, in the case of BPF
-programs, the account data holds the BPF bytecode. Program accounts are marked
-as executable once they are successfully deployed. The runtime will reject
-transactions that specify programs that are not executable.
+program will process this instruction. The program's account's owner specifies
+which loader should be used to load and execute the program and the data
+contains information about how the runtime should execute the program.
+
+In the case of [deployed BPF
+programs](developing/deployed-programs/overview.md), the owner is the BPF Loader
+and the account data holds the BPF bytecode.  Program accounts are permanently
+marked as executable by the loader once they are successfully deployed. The
+runtime will reject transactions that specify programs that are not executable.
+
+
+Unlike deployed programs, [builtins](developing/builtins/programs.md) are handled
+differently in that they are built directly into the Solana runtime.
 
 ### Accounts