Hedera Hashgraph is a public ledger. Nodes on the network collectively establish and maintain a consensus state for a set of application data.
Clients interact with that state through API calls sent to the nodes of the network.
To write to state, clients send transactions to a chosen node for subsequent gossip to the rest of the network, assignment of a consensus timestamp and a place in consensus order, and then application to state.
To read from state, clients send queries to a chosen node which, by looking at its local copy of state, can respond with the requested information.
Transactions cause the consensus state maintained by the mainnet nodes to change.
All transactions have an associated fee that reflects the burden it places on the mainnet nodes.
Below is the typical sequence for a transaction submitted to Hedera:
Queries do not require consensus processing and do not impact state.
Some queries are free, but most require that the client pay the node that responds to the query a fee for that service.
Below is the typical sequence for a query submitted to Hedera:
The above sequences for transactions and queries have certain variants and optimizations.
When querying a node for some aspect of state or the status of a transaction, a client will be able to stipulate that it desires a state proof for the response be included. A state proof is a cryptographic assertion from the network as a whole as to the veracity of the response. Consequently, even if the response comes from a single particular node, the client can be confident that it does indeed accurately reflect the true Hedera state at a given moment in time.
When implemented, state proofs can be created by main or a mirror node.
Once obtained by a client, a state proof can be archived in case of future arbitration.
State proofs will impose an additional fee so clients may choose to request a state proof only occasionally.
A large component of the size of a state proof (and so the contributor to the associated fee) will be due to the address book history. An optimization is possible where, if the requesting client already has the latest address book, that address book need not be included with the returned state proof - making it smaller and cheaper.
In the Hedera Consensus Service (HCS) model, the nodes of the mainnet do not apply the transaction to a copy of state they maintain. Instead, the transactions logically flow through the mainnet and, in so doing, are assigned a consensus timestamp and order in the corresponding topic. It is the nodes of some other application network (appnet) that, based on those timestamps, process the transaction and apply it to their copy of appnet state with application-specific rules.
The HCS model separates the roles of calculating consensus timestamps and order from that of validating transactions and maintaining appnet state and consequently offers advantages in performance and data confidentiality.
When submitting a transaction, a client can choose which node to use and so avoid malicious or slow nodes.
Unless there is some sort of relationship between a client and a particular node, a client should pick a node randomly.
A client can also protect itself from a node censoring its transactions or a node being offline by sending different versions (but with the same transaction identifier) of a transaction to multiple nodes. Even if both transactions are assigned a consensus timestamp by the network, only the first will be applied to state. The second will still have an associated fee, though smaller than the fee of the first.
If, after sending a transaction to a node and not being able to retrieve a record in some small period of time, a client could resend the transaction to another node, and keep trying until success. Even if almost 1/3 of nodes are maliciously not submitting the client’s transactions, then it would take on average x = 2/3(1) + 1/3(x+1) which gives x = 1.5 tries to succeed.
If the client maintains a list in memory of which nodes have successfully submitted its transactions in the past, or a list of those that have not, then the client can avoid malicious nodes. Such nodes will lose node fees if clients are avoiding it.
A client might occasionally try submitting to a node on the black list and thereby determine if the previous failed transaction submission was malicious or merely that the node was offline at the time.
If unsure about the honesty of a particular node, a client can choose to not query that node when asking about some aspect of state.
If unsure about the honesty of all nodes (as a general policy), a client can query multiple nodes and compare their answers.
State proofs provide an alternative mechanism by which clients can reassure themselves of the veracity of a node’s responses to queries.
Both models will have associated additional fees and a client should use those fees to determine the appropriate choice.
To help it stipulate an appropriate value for the payment for a query, a Client can first ask a node what would be the cost of a particular query, if actually sent. This sort of query is free to the client.
Mirrors are a separate network from the mainnet. Mirrors listen to the mainnet and provide value-add services that, if provided by the mainnet nodes, might impact their performance towards consensus. The fundamental role of mirrors is to facilitate retrieval and analysis of transaction history and the subsequent state.
Mirrors are separate business and will make different decisions about the services they wish to offer. For instance, a particular mirror node might choose to persist all transactions from genesis and build a business around making that history available. Another mirror might choose to store only crypto transfer transactions. A given enterprise might run its own mirror and store only transactions and state relevant to its business.
A mirror node may make its Hedera data available to external clients. It will be through the mirror that those clients would be able to examine the transaction history and corresponding state of some aspect of Hedera (whatever portion the mirror choose to support).
Mirror nodes can support a subscription mechanism by which clients can be sent any transaction records that meet certain criteria. For instance, a client could stipulate to a mirror that it wants to be notified of any and all transactions that impact a particular crypto account.
HCS appnets are a particularly important category of mirror clients. Members of an appnet will subscribe to a mirror (or perhaps multiple mirrors) to be notified of transactions submitted to a particular HCS topic.