_id => _pubkey variable renaming (#4419)

* wallet: rename *_account_id to *_account_pubkey

* s/from_id/from_pubkey/g

* s/node_id/node_pubkey/g

* s/stake_id/stake_pubkey/g

* s/voter_id/voter_pubkey/g

* s/vote_id/vote_pubkey/g

* s/delegate_id/delegate_pubkey/g

* s/account_id/account_pubkey/g

* s/to_id/to_pubkey/g

* s/my_id/my_pubkey/g

* cargo fmt

* s/staker_id/staker_pubkey/g

* s/mining_pool_id/mining_pool_pubkey/g

* s/leader_id/leader_pubkey/g

* cargo fmt

* s/funding_id/funding_pubkey/g

book/src/jsonrpc-api.md

@@ -290,8 +290,8 @@ An array consisting of vote accounts:
 Each VoteState will be a JSON object with the following sub fields:
 
 * `votes`, array of most recent vote lockouts
-* `node_id`, the pubkey of the node that votes using this account
-* `authorized_voter_id`, the pubkey of the authorized vote signer for this account
+* `node_pubkey`, the pubkey of the node that votes using this account
+* `authorized_voter_pubkey`, the pubkey of the authorized vote signer for this account
 * `commission`, a 32-bit integer used as a fraction (commission/MAX_U32) for rewards payout
 * `root_slot`, the most recent slot this account has achieved maximum lockout
 * `credits`, credits accrued by this account for reaching lockouts
@@ -302,7 +302,7 @@ Each VoteState will be a JSON object with the following sub fields:
 curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getEpochVoteAccounts"}' http://localhost:8899
 
 // Result
-{"jsonrpc":"2.0","result":[[[84,115,89,23,41,83,221,72,58,23,53,245,195,188,140,161,242,189,200,164,139,214,12,180,84,161,28,151,24,243,159,125],10000000,{"authorized_voter_id":[84,115,89,23,41,83,221,72,58,23,53,245,195,188,140,161,242,189,200,164,139,214,12,180,84,161,28,151,24,243,159,125],"commission":0,"credits":0,"node_id":[49,139,227,211,47,39,69,86,131,244,160,144,228,169,84,143,142,253,83,81,212,110,254,12,242,71,219,135,30,60,157,213],"root_slot":null,"votes":[{"confirmation_count":1,"slot":0}]}]],"id":1}
+{"jsonrpc":"2.0","result":[[[84,115,89,23,41,83,221,72,58,23,53,245,195,188,140,161,242,189,200,164,139,214,12,180,84,161,28,151,24,243,159,125],10000000,{"authorized_voter_pubkey":[84,115,89,23,41,83,221,72,58,23,53,245,195,188,140,161,242,189,200,164,139,214,12,180,84,161,28,151,24,243,159,125],"commission":0,"credits":0,"node_pubkey":[49,139,227,211,47,39,69,86,131,244,160,144,228,169,84,143,142,253,83,81,212,110,254,12,242,71,219,135,30,60,157,213],"root_slot":null,"votes":[{"confirmation_count":1,"slot":0}]}]],"id":1}
 ```
 
 ---

book/src/passive-stake-delegation-and-rewards.md

@@ -85,7 +85,7 @@ contains the following state information:
 
 * Account::lamports - The staked lamports.
 
-* `voter_id` - The pubkey of the VoteState instance the lamports are
+* `voter_pubkey` - The pubkey of the VoteState instance the lamports are
 delegated to.
 
 * `credits_observed` - The total credits claimed over the lifetime of the
@@ -109,7 +109,7 @@ program.
 
 * `account[0]` - RW - The StakeState::Delegate instance.
   `StakeState::Delegate::credits_observed` is initialized to `VoteState::credits`.
-  `StakeState::Delegate::voter_id` is initialized to `account[1]`
+  `StakeState::Delegate::voter_pubkey` is initialized to `account[1]`
 
 * `account[1]` - R - The VoteState instance.
 
@@ -127,7 +127,7 @@ reward.
 * `account[1]` - RW - The StakeState::Delegate instance that is redeeming votes
 credits.
 * `account[2]` - R - The VoteState instance, must be the same as
-`StakeState::voter_id`
+`StakeState::voter_pubkey`
 
 Reward is payed out for the difference between `VoteState::credits` to
 `StakeState::Delgate.credits_observed`, and `credits_observed` is updated to
@@ -181,7 +181,7 @@ the VoteState program or submitting votes to the program.
 
 The total stake allocated to a VoteState program can be calculated by the sum of
 all the StakeState programs that have the VoteState pubkey as the
-`StakeState::Delegate::voter_id`.
+`StakeState::Delegate::voter_pubkey`.
 
 ## Example Callflow
 
@@ -194,12 +194,12 @@ nodes since stake is used as weight in the network control and data planes.  One
 way to implement this would be for the StakeState to delegate to a pool of
 validators instead of a single one.
 
-Instead of a single `vote_id` and `credits_observed` entry in the StakeState
+Instead of a single `vote_pubkey` and `credits_observed` entry in the StakeState
 program, the program can be initialized with a vector of tuples.
 
 ```rust,ignore
 Voter {
-    voter_id: Pubkey,
+    voter_pubkey: Pubkey,
     credits_observed: u64,
     weight: u8,
 }

book/src/repair-service.md

@@ -46,6 +46,6 @@ The different protocol strategies to address the above challenges:
         * Current root
         * The set of all completed slots in the confirmed epochs (an epoch that was calculated based on a bank <= current root) past the current root
     
-    Observers of this gossip message with higher epochs (repairmen) send blobs to catch the lagging node up with the rest of the cluster. The repairmen are responsible for sending the slots within the epochs that are confrimed by the advertised `root` in gossip. The repairmen divide the responsibility of sending each of the missing slots in these epochs based on a random seed (simple blob.index iteration by N, seeded with the repairman's node_id). Ideally, each repairman in an N node cluster (N nodes whose epochs are higher than that of the repairee) sends 1/N of the missing blobs. Both data and coding blobs for missing slots are sent. Repairmen do not send blobs again to the same validator until they see the message in gossip updated, at which point they perform another iteration of this protocol.
+    Observers of this gossip message with higher epochs (repairmen) send blobs to catch the lagging node up with the rest of the cluster. The repairmen are responsible for sending the slots within the epochs that are confrimed by the advertised `root` in gossip. The repairmen divide the responsibility of sending each of the missing slots in these epochs based on a random seed (simple blob.index iteration by N, seeded with the repairman's node_pubkey). Ideally, each repairman in an N node cluster (N nodes whose epochs are higher than that of the repairee) sends 1/N of the missing blobs. Both data and coding blobs for missing slots are sent. Repairmen do not send blobs again to the same validator until they see the message in gossip updated, at which point they perform another iteration of this protocol.
 
     Gossip messages are updated every time a validator receives a complete slot within the epoch. Completed slots are detected by blocktree and sent over a channel to RepairService. It is important to note that we know that by the time a slot X is complete, the epoch schedule must exist for the epoch that contains slot X because WindowService will reject blobs for unconfirmed epochs. When a newly completed slot is detected, we also update the current root if it has changed since the last update. The root is made available to RepairService through Blocktree, which holds the latest root.

book/src/stake-delegation-and-rewards.md

@@ -22,11 +22,11 @@ The Vote account contains the following state information:
 
 * votes - The submitted votes.
 
-* `delegate_id` - An identity that may operate with the weight of this
+* `delegate_pubkey` - An identity that may operate with the weight of this
   account's stake. It is typically the identity of a fullnode, but may be any
 identity involved in stake-weighted computations.
 
-* `authorized_voter_id` - Only this identity is authorized to submit votes.
+* `authorized_voter_pubkey` - Only this identity is authorized to submit votes.
 
 * `credits` - The amount of unclaimed rewards.