Monitoring Transactions on the Hedera Network
In this session, Hedera Hashgraph’s Chief Developer Advocate, Ken Anderson, explains the difference between transaction receipts, records, and state proofs on the Hedera network. Then, he describes Mirror nodes and how they can be used in conjunction with the memo field to monitor your transactions in creative ways that fit your use case.
Ken Anderson | Chief Developer Advocate | Hedera Hashgraph
Distributed Ledger Technology (DLT) is not solving a storage problem. DLT is not solving a compute problem. DLT is solving a *trust* problem. Discover multiple ways to build trust with Hedera…and one you didn’t expect! What future will you build?
Monitoring Transactions on the Hedera Network
When you make an exchange on the Hedera network, there are several ways to ensure that the network carried out your transaction properly. You can ask a node for a receipt, request a record, or ask the network for a state proof. While these options may seem similar on the surface, they each have unique strengths and weaknesses. In this presentation, Hedera Hashgraph Chief Developer Advocate Ken Anderson walks us through the pros and cons of receipts, records, and state proofs. Then, he describes how you can utilize the memo field of a transaction creatively alongside Mirror nodes to monitor your transactions in a way personalized to your use case.
What Are Receipts?
The most basic type of transaction confirmation on the Hedera network is the receipt. A receipt represents a single node’s assertion that a transaction has been added to network consensus. Because receipts contain limited information, their creation is reasonably fast and free. However, as a single node’s perspective on consensus, receipts are fallible and inadmissible in a court of law. Therefore, receipts are best used for smaller transactions and everyday purchases.
To obtain a receipt, you simply ask a node whether the network came to consensus on your transaction. The node then returns the details of your transaction from its perspective. Because a single receipt is fallible, Ken Anderson recommends that you ask around. Instead of obtaining one receipt and trusting it completely, ask a series of nodes for receipts. If they all agree, you can reasonably believe the information that you have received. If there are irreconcilable variations in the receipts, you may have to query more nodes or take further action to determine the true state of your transaction. Because each receipt query is inexpensive, asking for multiple receipts is a fast and economical way to gain a secure, albeit informal, confirmation of your transaction.
What Are Records?
A record describes a single node’s understanding of consensus. Like receipts, records depend on a single node’s perspective, making them fallible documents. Unlike receipts, however, records contain extensive event information and consensus details, making them the only method to obtain smart contract results. Additionally, because they are more informative, records are not free to create. Therefore, records are best used for midsize or sensitize transactions which require detailed information or smart contract results.
To obtain a record, you must request its creation when you submit your transaction. Then, after the transaction is complete, you can query a node for the document.
What Are State Proofs?
State proofs are formal, signed documents which include official timestamps, records, and copies of a set of transactions. Because state proofs are comprehensive and cryptographically signed by a super majority of the network, they are secure, persistent, and potentially admissible in a court of law. However, creating state proofs can be expensive and time-consuming, as the multistage process involves every node in the network. Therefore, state proofs are best used for important or high value transactions.
When submitting your transaction, you can toggle the option to create a state proof. After the network reaches consensus, if you have requested a state proof, each node in the network will create a file documenting your transaction and the network’s consensus. Then, the nodes will group these files together into a state proof, with each node independently signing off on the proof’s legitimacy. You can then access this state proof alongside a standard record.
What are Mirror nodes?
Mirror nodes are peripheral nodes to the Hedera network which obtain all network information but do not participate in consensus. As independent nodes, they allow users to access network data without interrupting or slowing network functions. Mirror nodes can be created by any user, and do not require a stake.
A user who owns and operates a Mirror node can use that node to retrieve a high volume of receipts for free (barring the cost of running the node). Further, a Mirror node can be programmed to automatically monitor specific transactions. If you or your company need to receive receipts or records for a large number of transactions, a Mirror node may provide the quickest and most cost-effective way to do so.
One creative way to use Mirror nodes involves the memo field. When submitting a transaction, in addition to information including the node ID and record boolean, a user can add up to 100 bytes of characters into the memo field. This space can be used for small text or encrypted messages, hashes, or other codes. A Mirror node can then be set up to look for transactions that have certain messages, automatically responding to them by collecting receipts or performing other functions.
In the slide below, Ken Anderson details some creative use cases which combine Mirror nodes and clever uses of the memo field.