In a typical decentralized ledger, if you need to cryptographically verify that a particular fact about a ledger — like a transaction or a balance — is true, you need to run the entire blockchain and validate the blockchain from the genesis till the point in time that is of interest.
Hedera has defined an innovative way to provide a cryptographic proof for the blockchain where any consensus node in the Hedera network can provide a portable proof that can be cryptographically verified and trusted, even if you don’t trust the node. The trust in the state proof is derived from the trust in the supermajority of stake in the Hedera nodes. For a more detailed understanding of State Proofs, check out this this blog posting by Paul Madsen, Technical Lead at Hedera: https://www.hedera.com/blog/state-proofs-on-hedera. Ahead of the launch of the full state proof capability, we're happy to announce the availability of a subset of that functionality called "State Proof Alpha", which is available on the testnet today and the mainnet soon.
Using State Proof Alpha, users can now obtain a cryptographic proof that a particular transaction took place on Hedera, and what the results of executing it were. A Hedera mirror node provides this portable proof for the transaction records that can be independently verified to ensure their validity. Similar to the promise of what will eventually be full state proofs on Hedera, the user can trust this state proof alpha served by mirror nodes, even when the user does not trust the mirror nodes. The validity of the proof can be checked independently to ensure that the Hedera mainnet truly had reached consensus on a specific transaction.
Keep reading below to understand how State Proof Alpha works and visit the official documentation at https://docs.hedera.com/guides/docs/mirror-node-api/cryptocurrency-api#state-proof-alpha to get started.
What is State proof alpha?
Here’s how State Proof Alpha works:
Obtaining the state proof:
- A user requests for a state proof alpha for a particular transaction ID to the mirror node REST API.
- Hedera mirror node responds with three artifacts returned in base64 encoding:
- A transaction record file that contains the transaction record for the specified transaction.
- A set of signature files signed by individual consensus nodes in the Hedera network.
- The address book that contains the public keys of the Hedera council nodes.
- This set of artifacts are a portable proof that can be independently validated.
Validating the state proof:
- The user first validates the address book. This can be done in various ways: The user could query the address book using a Hedera API call to the network as explained here or view the public keys here.
- Once the user has validated the address book, now they can trust the address book. With this trust, they parse the address book to create a map of Hedera node ID to their corresponding public keys
- The user then uses these public keys to validate if at least a third of these nodes had provided their signatures on the hash of the transaction record file.
- A hash of the transaction record file’s contents is generated and is verified against the hash contained in the signature files.
- Assuming that at least a third of these nodes had matching hashes, the user can then trust the transaction records file.
- With this trust in the transaction records file, the user can then parse this file and obtain an individual record for the transaction that they are interested in.
Obtaining the state proof:
You can view the mirror node state proof rest API documentation here.
State proof alpha mirror node rest API request: