Grammar corrections PR#23206 Review Fixes (#23291)

* Accounts page grammar edits

* calling-between-programs page grammar edits

* PR #23206 "Grammar Corrections" review fixes

* Update docs/src/developing/clients/jsonrpc-api.md

Co-authored-by: Tyera Eulberg <teulberg@gmail.com>

* Update docs/src/developing/programming-model/accounts.md

Co-authored-by: Tyera Eulberg <teulberg@gmail.com>

Co-authored-by: Tyera Eulberg <teulberg@gmail.com>

docs/src/developing/clients/jsonrpc-api.md

@@ -107,7 +107,8 @@ Unstable methods may see breaking changes in patch releases and may not be suppo
 
 ## Request Formatting
 
-To make a JSON-RPC request, send an HTTP POST request with a `Content-Type: application/json` header. The JSON request data should contain 4 fields:
+To make a JSON-RPC request, send an HTTP POST request with a `Content-Type:
+application/json` header. The JSON request data should contain 4 fields:
 
 - `jsonrpc: <string>`, set to `"2.0"`
 - `id: <number>`, a unique client-generated identifying integer

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

@@ -23,11 +23,11 @@ uses an _address_ to look up an account. The address is a 256-bit public key.
 
 ## Signers
 
-Transactions may include digital [signatures](terminology.md#signature)
-corresponding to the account's public keys referenced by the transaction. Such
-signatures signify that the holder of the
-account's private key signed, and thus, "authorized" the transaction. In this case,
-the account is referred to as a _signer_. Whether an account is a signer or not
+Transactions include one or more digital [signatures](terminology.md#signature)
+each corresponding to an account address referenced by the transaction. Each of these
+addresses must be the public key of an ed25519 keypair, and the signature signifies
+that the holder of the matching private key signed, and thus, "authorized" the transaction.
+In this case, the account is referred to as a _signer_. Whether an account is a signer or not
 is communicated to the program as part of the account's metadata. Programs can
 then use that information to make authority decisions.
 

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

@@ -51,6 +51,10 @@ that are consumed as the program performs various operations and bounds that the
 program may not exceed. When the program consumes its entire budget or exceeds
 a bound, then the runtime halts the program and returns an error.
 
+Note: The compute budget currently applies per-instruction but is moving toward
+a per-transaction model. For more information see [Transaction-wide Compute
+Budget](#transaction-wide-compute-budget).
+
 The following operations incur a compute cost:
 
 - Executing BPF instructions
@@ -87,8 +91,8 @@ Then the program
 
 - Could execute 200,000 BPF instructions, if it does nothing else.
 - Could log 2,000 log messages.
-- Can not exceed 4k of stack usage.
-- Can not exceed a BPF call depth of 64.
+- Cannot exceed 4k of stack usage.
+- Cannot exceed a BPF call depth of 64.
 - Cannot exceed 4 levels of cross-program invocations.
 
 Since the compute budget is consumed incrementally as the program executes, the

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

@@ -157,7 +157,7 @@ perform, and any additional information those operations may need above and
 beyond what the accounts contain.
 
 Programs are free to specify how information is encoded into the instruction
-data byte array. The choice of how data is encoded should take into calculate the
+data byte array. The choice of how data is encoded should consider the
 overhead of decoding, since that step is performed by the program on-chain. It's
 been observed that some common encodings (Rust's bincode for example) are very
 inefficient.