doc: entry::Entry: More details on the `transactions` field (#29949)

entry/src/entry.rs

@@ -111,7 +111,7 @@ pub struct Api<'a> {
 /// field points to Transactions that took place shortly before `hash` was generated.
 ///
 /// If you multiply `num_hashes` by the amount of time it takes to generate a new hash, you
-/// get a duration estimate since the last Entry. Since processing power increases
+/// get a duration estimate since the last `Entry`. Since processing power increases
 /// over time, one should expect the duration `num_hashes` represents to decrease proportionally.
 /// An upper bound on Duration can be estimated by assuming each hash was generated by the
 /// world's fastest processor at the time the entry was recorded. Or said another way, it
@@ -119,7 +119,19 @@ pub struct Api<'a> {
 /// hash was computed by the world's fastest processor at that time. The hash chain is both
 /// a Verifiable Delay Function (VDF) and a Proof of Work (not to be confused with Proof of
 /// Work consensus!)
-
+///
+/// The solana core protocol currently requires an `Entry` to contain `transactions` that are
+/// executable in parallel. Implemented in:
+///
+/// * For TPU: `solana_core::banking_stage::BankingStage::process_and_record_transactions()`
+/// * For TVU: `solana_core::replay_stage::ReplayStage::replay_blockstore_into_bank()`
+///
+/// All transactions in the `transactions` field have to follow the read/write locking restrictions
+/// with regard to the accounts they reference. A single account can be either written by a single
+/// transaction, or read by one or more transactions, but not both.
+///
+/// This enforcement is done via a call to `solana_runtime::accounts::Accounts::lock_accounts()`
+/// with the `txs` argument holding all the `transactions` in the `Entry`.
 #[derive(Serialize, Deserialize, Debug, Default, PartialEq, Eq, Clone)]
 pub struct Entry {
     /// The number of hashes since the previous Entry ID.