spec: add proving / authorization diagram

docs/protocol/src/crypto/transaction_signing.md

@@ -16,22 +16,71 @@ Proofs (ZKPs) are generated as part of the transaction build process.
 The signing process first takes a `TransactionPlan` and returns
 the `AuthorizationData`, essentially a bundle of signatures over
 the *effect hash*, which can be computed directly from the plan data. You can
-read more about the details of the effect hash computation below. 
+read more about the details of the effect hash computation below.
 
-The building process takes the `TransactionPlan`, generates the proofs, and puts the `Transaction` together with dummy signatures, that can be filled in once the
-signatures from the `AuthorizationData` are ready[^1]. The Penumbra
-protocol was designed to only require the custodian, e.g. the hardware wallet
+The building process takes the `TransactionPlan`, generates the proofs, and constructs a
+transaction with dummy signatures, that can be filled in once the
+signatures from the `AuthorizationData` are ready[^1]. This intermediate state
+of the transaction without the full authorizing data is called the `UnauthTransaction`.
+
+The Penumbra protocol was designed to only require the custodian, e.g. the hardware wallet
 environment, to do signing, as the generation of ZKPs can be done without access to signing keys, requiring only witness data and viewing keys.
 
+A figure showing how these pieces fit together is shown below:
+
+```
+╔════════════════════════╗
+║         Authorization  ║
+║                        ║
+║┌──────────────────────┐║
+║│ Spend authorization  │║
+║│         key          │║    ┌───────────────────┐
+║└──────────────────────┘║    │                   │
+║                        ║───▶│ AuthorizationData │──┐
+║                        ║    │                   │  │
+║┌──────────────────────┐║    └───────────────────┘  │
+║│      EffectHash      │║                           │
+║└──────────────────────┘║                           │
+║                        ║                           │
+║                        ║                           │
+╚════════════▲═══════════╝                           │
+             │                                       │
+             │                                       │      ┌───────────┐
+ ┌───────────┴───────────┐                           │      │           │
+ │                       │                           └┬────▶│Transaction│
+ │    TransactionPlan    │                            │     │           │
+ │                       │                            │     └───────────┘
+ └───────────┬───────────┘                            │
+             │                                        │
+             │                                        │
+             │                                        │
+ ╔═══════════▼════════════╗                           │
+ ║                Proving ║                           │
+ ║                        ║                           │
+ ║┌──────────────────────┐║                           │
+ ║│     WitnessData      │║                           │
+ ║└──────────────────────┘║   ┌───────────────────┐   │
+ ║                        ║   │                   │   │
+ ║                        ╠──▶│ UnauthTransaction ├───┘
+ ║┌──────────────────────┐║   │                   │
+ ║│   Full viewing key   │║   └───────────────────┘
+ ║└──────────────────────┘║
+ ║                        ║
+ ║                        ║
+ ║                        ║
+ ╚════════════════════════╝
+
+```
+
 Transactions are signed used the [`decaf377-rdsa` construction](../crypto/decaf377-rdsa.md). As described briefly in that section, there are two signature domains used in Penumbra: `SpendAuth` signatures and `Binding` signatures.
 
 ## `SpendAuth` Signatures
 
 `SpendAuth` signatures are included on each `Spend` and `DelegatorVote` action
 (see [Multi-Asset Shielded Pool](../shielded_pool.md) and [Governance](../governance.md)
-for more details on `Spend` and `DelegatorVote` actions respectively). 
+for more details on `Spend` and `DelegatorVote` actions respectively).
 
-The `SpendAuth` signatures are created using a randomized signing key $rsk$ and the corresponding randomized verification key $rk$ provided on the action. The purpose of the randomization is to prevent linkage of verification keys across actions. 
+The `SpendAuth` signatures are created using a randomized signing key $rsk$ and the corresponding randomized verification key $rk$ provided on the action. The purpose of the randomization is to prevent linkage of verification keys across actions.
 
 The `SpendAuth` signature is computed using the `decaf377-rdsa` `Sign` algorithm
 where the message to be signed is the *effect hash* of the entire transaction
@@ -133,6 +182,6 @@ where the message to be signed is the *auth hash* as described above, and the
 `decaf377-rdsa` domain is `Binding`. The binding signing key is computed using the random blinding factors for each balance commitment.
 
 [^1]: At this final stage we also generate the last signature: the binding signature, which can only be added
-once the rest of the transaction is ready since it is computed over the proto-encoded `TransactionBody`. 
+once the rest of the transaction is ready since it is computed over the proto-encoded `TransactionBody`.
 
 [^2]: https://github.com/zcash/zips/issues/651