Change validator terms (#963)

Signed-off-by: Michael Garber <[email protected]>

HIP/hip-1.md

@@ -32,7 +32,7 @@ There are three kinds of HIP:
 
     **c. Mirror:** A mirror node runs software designed to retrieve all, or some of the records generated by the Hedera consensus nodes and make those records available to users in a way that is meaningful, reliable, and trustworthy.
 
-    **d. Application:** Application standards may be used to standardize software in the Hedera ecosystem that aren't mirror or consensus nodes. This includes application network software, external contract validators, multi-sig oracles, persistence mechanisms, enterprise software plugins, etc. An example of an Application standard would be the Stablecoin Contract and Non-fungible Token Contract written in Java as a layer-2 solution using the Hedera Consensus service to maintain trust.
+    **d. Application:** Application standards may be used to standardize software in the Hedera ecosystem that aren't mirror or consensus nodes. This includes application network software, external contract consensus nodes, multi-sig oracles, persistence mechanisms, enterprise software plugins, etc. An example of an Application standard would be the Stablecoin Contract and Non-fungible Token Contract written in Java as a layer-2 solution using the Hedera Consensus service to maintain trust.
 
 2. An **Informational** HIP describes a Hedera design issue or provides general guidelines or information to the Hedera community but does not propose a new feature. Informational HIPs do not necessarily represent a Hedera community consensus or recommendation, so users and implementers are free to ignore Informational HIPs or follow their directions.
 
@@ -162,7 +162,7 @@ The possible paths of the status of HIPs are as follows:
 - __Idea__ - An idea that is pre-draft. This is not tracked within the HIP Repository.
 - __Draft__ - The first formally tracked stage of a HIP in development. A HIP is merged by a HIP Editor into the HIP repository when properly formatted.
 - __Review__ - A HIP Author marks a HIP as ready for and requesting Editorial Review.
-- __Deferred__ - A HIP that is already being addressed in another HIP
+- __Deferred__ - A HIP under consideration for future implementation, but not set for immediate action.
 - __Withdrawn__ - The HIP Author(s) have withdrawn the proposed HIP. This state has finality and can no longer be resurrected using this HIP number. If the idea is pursued at a later date - it is considered a new proposal.
 - __Stagnant__ - Any HIP in Draft or Review if inactive for a period of 6 months or greater, is moved to Stagnant. A HIP may be resurrected from this state by Authors or HIP Editors through moving it back to Draft.
 - __Rejected__ - Throughout the discussion of a HIP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This helps record the thought process behind the final version of the HIP and prevents people from bringing up the same rejected idea again in subsequent discussions.

HIP/hip-11.md

@@ -84,18 +84,18 @@ Source code of the standard Ethereum full node (e.g. geth node) is forked and mo
  . Reading of the balances of other accounts: the layer-2 node could listen to the mirror node transaction records to find out the balances, and calculate the balances accordingly. We could modify the `BALANCE` opcode of the EVM to fetch this information from a mirror node.
 
 ### Properties of this solution
-* Trust: End-users can trust this system as long as they can trust a configured number of community validators is honest.
-* Transparency: All validator signatures can be verified through the record of the scheduled transactions. The p2p gossip for transactions between these layer-2 nodes is logged on HCS and can be verified/audited.
+* Trust: End-users can trust this system as long as they can trust a configured number of community consensus nodes is honest.
+* Transparency: All consensus node signatures can be verified through the record of the scheduled transactions. The p2p gossip for transactions between these layer-2 nodes is logged on HCS and can be verified/audited.
 Ethereum tool chain: All existing Ethereum tools should continue to work without any modification, at least in theory.
-* State: the state is maintained by the validators and it does not add any tax on Hedera. The state is maintained in the layer-2 smart contracts. Hedera only executes the HAPI transactions (including scheduled transactions), and maintains the accounts and their hbar/token balances.
+* State: the state is maintained by the consensus nodes and it does not add any tax on Hedera. The state is maintained in the layer-2 smart contracts. Hedera only executes the HAPI transactions (including scheduled transactions), and maintains the accounts and their hbar/token balances.
 * Cost: Expected to be significantly cheaper than Ethereum gas costs, but slightly more expensive than native HAPI transactions. Very comparable to the cost of interoperability transactions through decentralized bridges.
 * Scale: The scale is really dependent on the number of parallel instances of these layer-2 nodes and the number of nodes in each of them. The scale from Hedera mainnet perspective is really the scale of the native cryptotransfer, HCS submit message transactions, and scheduled transactions.
 * Latency: overall latency will involve sending transactions through HCS, and then submitting the scheduled transaction. Assuming each of these takes around 5-10 seconds, the overall latency is likely to be around 15-25 seconds. 
 * Finality: Transactions notified by mirror node or HCS can be considered to be 100% final.
 
 ### Node incentives
-To bootstrap, Hedera could incentivize a set of validators. But Hedera does not really define the incentive model for this network. There could be multiple independent instances of these networks and the participants can decide on the incentive models and prices depending on the use cases they serve. The incentive model could be as simple as “everyone who participates gets a share of fees”, which would incentivize smaller networks, or “a selected subset of validators (e.g. determined by a hashing function using the latest consensus timestamp) will get compensated”. In both cases making sure that there is some skin in the game for validators (maybe staked HBAR) would be good to prevent Sybil Attacks.
-The validators are known to the smart contract, and the smart contract is coded to distribute the ‘fees’ to the validators equally between the validators who are “active” (defined as those who successfully signed the last m of n transactions). So, if a validator falls off the network, very quickly they will stop receiving payments. The community can write this logic so that this set of ‘active’ validators is deterministically calculated on each validator.
+To bootstrap, Hedera could incentivize a set of consensus nodes. But Hedera does not really define the incentive model for this network. There could be multiple independent instances of these networks and the participants can decide on the incentive models and prices depending on the use cases they serve. The incentive model could be as simple as “everyone who participates gets a share of fees”, which would incentivize smaller networks, or “a selected subset of consensus nodes (e.g. determined by a hashing function using the latest consensus timestamp) will get compensated”. In both cases making sure that there is some skin in the game for consensus nodes (maybe staked HBAR) would be good to prevent Sybil Attacks.
+The consensus nodes are known to the smart contract, and the smart contract is coded to distribute the ‘fees’ to the consensus nodes equally between the consensus nodes who are “active” (defined as those who successfully signed the last m of n transactions). So, if a consensus node falls off the network, very quickly they will stop receiving payments. The community can write this logic so that this set of ‘active’ consensus nodes is deterministically calculated on each consensus node.
 
 
 ### Deployment and configuration:

HIP/hip-13.md

@@ -14,15 +14,15 @@ updated: 2021-11-30
 
 ## Abstract
 
-The Public Key Infrastructure (PKI) of today is highly centralised with a handful of certificate authorities(CAs) being responsible to validate digital identities(such as domains) by vouching for public keys associated with said identities. This system if highly vulnerable as if any one of the existing list of trusted CAs is compromised so is the entire security of the internet. One solution to this is DNS-based Authentication of Named Entities(DANE) which enables domain owners to store a TSLA record in the Domain Name System(DNS) that defines a contract for how clients can trust a public key is in fact owned by said domain before proceeding to establish a TLS connection. However DANE relies on DNSSEC which relies on a chain of trust akin to that in existing CA PKI as previously mentioned hence is susceptible to similar attacks.
+The Public Key Infrastructure (PKI) of today is highly centralised with a handful of certificate authorities(CAs) being responsible to process digital identities(such as domains) by vouching for public keys associated with said identities. This system if highly vulnerable as if any one of the existing list of trusted CAs is compromised so is the entire security of the internet. One solution to this is DNS-based Authentication of Named Entities(DANE) which enables domain owners to store a TSLA record in the Domain Name System(DNS) that defines a contract for how clients can trust a public key is in fact owned by said domain before proceeding to establish a TLS connection. However DANE relies on DNSSEC which relies on a chain of trust akin to that in existing CA PKI as previously mentioned hence is susceptible to similar attacks.
 
 By moving DNS (w/ DANE enabled) onto a secure decentralised network such as Hedera security issues resulting from the chain of trust in existing systems are mitigated and if widely adopted would render all existing CAs, DNS stakeholders(ICANN, domain registrars) obsolete.
 
 ## Motivation
 
 The Hedera Public Ledger is a secure scalable decentralised ledger making it an ideal candidate to supersede existing centralised DNS and PKI systems. Currently the most secure implementations of these systems rely on a chain of trust which is compromised if at least 1-of-m entities in the chain is compromised. The shortcomings inherent to this chain of trust can be mitigated by being replaced with the aBFT consensus of Hedera, hence in order to compromise even a single DNS Resource Record(RR) an attacker must control at least 1/3 of the consensus vote.
 
-Furthermore, the proposed Hedera Name Service(HNS) excels existing systems by enabling the principal owner/s of a domain registered on HNS the ability to update any of their domain's RR at consensus finality speeds(currently <5 seconds), whereas existing infrastructure takes about 1 day for domain propagation. The effective latency would be slightly higher than this as client browsers making for example domain resolution requests would do so to Hedera Mirror Nodes to reduce unnecessary load on MainNet nodes, hence the effective latency would be the MainNet latency offset by the time it takes for any given Mirror Node to reflect the latest consensus round HNS updates. Furthermore, Mirror Nodes(possibly serving as dedicated HNS/DNS resolvers) would respond to requests with a state proof that the client browser would validate either via an HNS browser extension client or the browser's built-in HNS client(assuming browser developers find value in doing so). In addition, any other operations facilitated by HNS such as domain atomic swaps or transfers would also be executed at such speeds, which again is orders of magnitude faster than existing systems that can take up to 7 days to process a domain transfer.
+Furthermore, the proposed Hedera Name Service(HNS) excels existing systems by enabling the principal owner/s of a domain registered on HNS the ability to update any of their domain's RR at consensus finality speeds(currently <5 seconds), whereas existing infrastructure takes about 1 day for domain propagation. The effective latency would be slightly higher than this as client browsers making for example domain resolution requests would do so to Hedera Mirror Nodes to reduce unnecessary load on MainNet nodes, hence the effective latency would be the MainNet latency offset by the time it takes for any given Mirror Node to reflect the latest consensus round HNS updates. Furthermore, Mirror Nodes(possibly serving as dedicated HNS/DNS resolvers) would respond to requests with a state proof that the client browser would process either via an HNS browser extension client or the browser's built-in HNS client(assuming browser developers find value in doing so). In addition, any other operations facilitated by HNS such as domain atomic swaps or transfers would also be executed at such speeds, which again is orders of magnitude faster than existing systems that can take up to 7 days to process a domain transfer.
 
 ## Rationale
 

HIP/hip-171.md

@@ -36,7 +36,7 @@ As a developer, I want to know what account sent an HCS message from the message
 
 A `payer_account_id` field should be added to the JSON response of `/api/v1/topics/{topicId}/messages`, `/api/v1/topics/{topicId}/messages/{sequenceNumber}`, and `/api/v1/topics/messages/{consensusTimestamp}`.
 
-We already have a `topic_message.payer_account_id` in the table but it is only populated if `chunkInfo` is present in the protobuf. Services validates that if `chunkInfo` is populated that the payer of the transaction must match `chunkInfo.payerAccountId`. So really we can just always populate it with the `transaction.payer_account_id` so it's present for both chunked and non-chunked messages. Then we can return it on the REST API without incurring the cost of a join against the transaction table. This will require a database migration to backfill this data for entries that are null.
+We already have a `topic_message.payer_account_id` in the table but it is only populated if `chunkInfo` is present in the protobuf. Services processes that if `chunkInfo` is populated that the payer of the transaction must match `chunkInfo.payerAccountId`. So really we can just always populate it with the `transaction.payer_account_id` so it's present for both chunked and non-chunked messages. Then we can return it on the REST API without incurring the cost of a join against the transaction table. This will require a database migration to backfill this data for entries that are null.
 
 So the full topic message REST API response (with consideration for the expanding transactionID object) should become:
 

HIP/hip-173.md

@@ -34,24 +34,24 @@ exception is to be if the existing schedule has an explicit `payerAccountID` dif
 
 ## Motivation
 
-Suppose a validator network is monitoring a stream of events, where each event `e` is uniquely identified
+Suppose a consensus node network is monitoring a stream of events, where each event `e` is uniquely identified
 by a hash `He`, and should trigger the scheduling of a single related transaction `Xe` that needs a majority 
-of the validators' signatures to execute. 
+of the consensus nodes' signatures to execute. 
 
-Suppose also that the validators all set `memo=He` when trying to schedule transaction `Xe`. Then by the 
+Suppose also that the consensus nodes all set `memo=He` when trying to schedule transaction `Xe`. Then by the 
 uniqueness of the memos, there is no risk that two identical `ScheduleCreate`s are _actually_ intended for 
 two different events. 
 
-Nonetheless, with current network behavior, only the first validator to submit the `ScheduleCreate` for 
-event `e` will have a "normal" workflow. All the other validators will receive `IDENTICAL_SCHEDULE_ALREADY_CREATED`, 
+Nonetheless, with current network behavior, only the first consensus node to submit the `ScheduleCreate` for 
+event `e` will have a "normal" workflow. All the other consensus nodes will receive `IDENTICAL_SCHEDULE_ALREADY_CREATED`, 
 and need to submit a second `ScheduleSign` transaction to attach their signature to the scheduled `Xe` transaction.
 
-This is at best inconvenient, as the network is enforcing protection the validator network simply does not need.
+This is at best inconvenient, as the network is enforcing protection the consensus node network simply does not need.
 
 ## Rationale
 
 Improve the user experience when scheduling transactions on the network, especially in the use case
-of a validator network as above.
+of a consensus node network as above.
 
 ## Specification
 
@@ -88,7 +88,7 @@ keep the same semantics for their `ScheduleCreate` transactions, since the defau
 
 ## Security Implications
 
-We do not see any security implications for this change. If a client such as a validator network 
+We do not see any security implications for this change. If a client such as a consensus node network 
 opts-in to merged scheduling, but cannot ensure duplicate `ScheduleCreate` transactions are 
 always functionally equivalent, it could suffer a correctness failure. But this would be a form 
 of user error, not a problem with the network.

HIP/hip-179.md

@@ -54,7 +54,7 @@ A websocket based proxy server adhering to CAIP-25 and CAIP-27 JSON-RPC calls
 will be used to provide signing services. Clients will need to configure and
 secure access to this websocket service and then use the provided handshake and
 provider request APIs to sign their transactions. Clients will then either need
-to submit the signed transaction or validate the submitted transaction was
+to submit the signed transaction or verify the submitted transaction was
 successfully submitted by the service.
 
 ### Signing Proxy Server (CAIP-25 and CAIP-27)
@@ -87,7 +87,7 @@ request, `hedera_signTransaction` and `hedera_sendTransaction`.
 
 This JSON-RPC method signs a transaction that can be submitted to the network
 via the existing SDK methods. It is expected there will be some operation on the
-other end to validate the signature, possibly including user approval.
+other end to process the signature, possibly including user approval.
 
 There is one required and one optional parameter: The required parameter
 is `transaction`, which will be the hex encoded protobuf message that is being
@@ -185,7 +185,7 @@ sensible error code and description
 
 This JSON-RPC method signs a transaction and then submits it to the hedera
 network. It is expected there will be some operation on the other end to
-validate the signature, possibly including user approval.
+process the signature, possibly including user approval.
 
 There is one required and one optional parameter: The required parameter
 is `transaction`, which will be the hex encoded protobuf message that is being

HIP/hip-18.md

@@ -563,7 +563,7 @@ new TokenCreateTransaction()
 
 In this example, the token created would require 100 tokens with entity ID 0.0.987 to be transferred into the account
 with entity ID 0.0.123. Account 0.0.123 could obviously be a single individual’s account, or it could be a
-multisignature account managed by an HCS based validator network, as we’ve recently seen in Greg Scullard’s NFT auction
+multisignature account managed by an HCS based consensus node network, as we’ve recently seen in Greg Scullard’s NFT auction
 demo ([10](https://www.youtube.com/watch?v=hCPXKR1e7Ro)).
 
 This could be expanded to include up to 10 custom fees per token.

HIP/hip-206.md

@@ -149,7 +149,7 @@ Associate and Dissociate are the `associateToken`, `associateTokens`,
 To support contracts controlling features like minting and burning the defined
 but up until now unused field `contractID` in the `Key` protobuf message will be
 utilised. When a token has a contract key as the admin key or one of the admin
-keys then that key is considered validated if the `CALLER` of the relevant
+keys then that key is considered processed if the `CALLER` of the relevant
 method is the contract identified in the call. This is the effect of a `CALL`
 operation in the EVM.