Skip to main content
This article presents advanced examples of proof verification using liteservers. Verifying any data received from a node is essential for trustless interaction with the blockchain. However, this article covers only a portion of the trustless communication process with a liteserver. It assumes you have verified the block hash received from a liteserver or any other source. Block hash verification is a more advanced topic. It requires syncing key blocks, validating block signatures, or both. This topic will be covered in a future article. Nonetheless, even using only the examples provided here can significantly reduce the probability of accepting incorrect data from a liteserver.

​
Block header

Suppose we have a known block ID:
not runnable
Request the corresponding block header from a liteserver. The liteserver’s response includes a header_proof BoC. After deserializing the BoC, we obtain the following cell:
not runnable
Deserialize the cell according to the block TL-B schema:
Next, we need to verify that the seqno in the deserialized block matches the seqno of the block we know. After that, we compute hash_1 for the single Merkle proof reference and compare it to our block hash.
Now, we can trust all other data in the cell. Checking proof examples: Python, Kotlin, C++

​
Full block

In the liteserver.getBlock method, proof verification is performed in Block header. However, it includes full cells instead of pruned branches for the value flow, state update, and block extra schemas.

​
Shard block

Shard proofs verify that a shard reference is stored in the masterchain block provided to the liteserver. These proofs are necessary when calling the following methods:
  • liteServer.getShardInfo
  • liteServer.getAccountState
  • liteServer.runSmcMethod
To request shard info from the liteserver for the masterchain block mentioned above, we can execute the following code:
The liteserver response contains the BlockIdExt of the shard block:
not runnable
Shard proof BoC: The shard_descr BoC can be used if the liteserver is trusted. After deserializing the shard proof BoC, two root cells are obtained:
not runnable
The first root is a masterchain block Merkle proof, which must be verified using the check_block_header function:
not runnable
The cell
not runnable
It is a Merkle update of the ShardState TL-B schema. The resulting new hash should be stored. After verifying that the only Merkle proof cell reference Hash_1 matches the known block hash and storing the new ShardState hash, proceed to validate the second shard proof cell:
not runnable
The Merkle proof reference in this cell has the prefix 9023AFE2, corresponding to the ShardStateUnsplit TL-B schema. This reference’s Hash_1 must match the hash stored in the previous step:
  • Why? — We can trust the associated cell data because the block header proof is verified. Therefore, the new hash from the ShardState Merkle update is considered trusted. We must confirm the hashes match to validate the second cell’s data.
Now, proceed to deserialize the second cell:
Since this cell is trusted, we can also trust the shard block data (ShardStateUnsplit -> custom -> shard_hashes -> 0 (shrdblk wc) -> leaf).

​
Account state

Next, let’s prove the state of account EQBvW8Z5huBkMJYdnfAEM5JqTNkuWX3diqYENkWsIL0XggGG for the same masterchain block referenced at the beginning of this article. The liteserver response includes the masterchain block ID, which must match the one sent to the liteserver, the shard block ID, and a shard_proof BoC, which must be verified as described above, along with a proof BoC and a state BoC. After verifying the shard_proof, the proof and state cells must be deserialized. The proof cell must contain exactly two root cells:
not runnable
The first root is a Merkle proof for the shard block, whose hash we have already verified and trusted.
not runnable
As in the shard_proof verification, the check_block_header function must validate the block cell and record the new StateUpdate hash. Next, deserialize the second root (state_cell) and verify that its Hash_1 matches the previously recorded hash:
Once the hash matches, the state_cell can be trusted. Its structure is as follows: The only Merkle proof reference has the prefix 9023AFE2, which corresponds to the ShardStateUnsplit TL-B schema. Therefore, it must be deserialized accordingly.
We now need the account field, which is of type ShardAccounts. ShardAccounts is a HashmapAugE, where the key is the address hash_part, the value is type ShardAccount, and the extra field is type DeepBalanceInfo. Parsing the address EQBvW8Z5huBkMJYdnfAEM5JqTNkuWX3diqYENkWsIL0XggGG, we obtain the hash_part equal to: 50368879097771769677871174881221998657607998794347754829932074327482686052226 We then use this key to retrieve the corresponding value from the Hashmap.
We need to store the values of last_trans_hash and last_trans_lt, as they can be used later to retrieve the account’s transactions. Let’s examine the entire cell containing this data.
not runnable
This is a regular cell with level 1, containing a single reference — the pruned account data. We compute the Hash_1 of this pruned branch, which serves as the trusted account state hash: 8282d13bf66b9ace1fbf5d3abd1c59cc46d61af1d47af1665d3013d8f9e47488. The next step is to deserialize the state BoC:
not runnable
Compute its representation hash, and verify that it matches the trusted hash obtained from the pruned data: 8282d13bf66b9ace1fbf5d3abd1c59cc46d61af1d47af1665d3013d8f9e47488. Finally, the BoC is deserialized using the account TL-B schema.
At this point, the account state data is verified and trusted.

​
Account transactions

For the liteServer.getTransactions request, we must provide the lt and hash of the transaction to start from. If we want to retrieve an account’s latest transactions, we can extract the lt and hash from the trusted ShardAccount, as described above. When the liteserver returns the transactions, it provides a BoC containing the requested number of transaction roots. Each root is a cell that should be deserialized using the transaction TL-B schema. For the first transaction cell, verify that its hash matches the last_trans_hash from the account state. Then, store the prev_trans_hash field, compare it to the hash of the second transaction root, and continue the verification process in this manner.

​
Block transactions

Next, we query the liteserver for the list of transactions belonging to the block we started with at the beginning of this article. The liteserver response includes ids field with the transaction list and a proof BoC. The first step is to deserialize the proof:
not runnable
We must verify the block header proof to trust the cell’s contents. Once verified, we can deserialize it using the block TL-B schema.
After successful deserialization, we should extract and remember the following field: block -> extra -> account_blocks. This field has the type ShardAccountBlocks, which is a HashmapAugE, where:
  • The key is the address hash_part.
  • The value is of type AccountBlock.
  • The extra data is a CurrencyCollection.
Now, let’s check the ids field:
For each transaction, we should find its corresponding entry in the account_blocks we remembered and verify that their hashes match:
:::note In this example, checking the ids field was optional — we could have retrieved all transactions directly from the account blocks. However, verifying the transaction proofs becomes essential when using the liteServer.listBlockTransactionsExt method, and you must compare transaction hashes. :::

​
Config

Request the following config params from the liteserver: 1, 4, 5, 7, 8, and 15 for liteServer.getConfigAll, where all parameters are returned, and the proof verification remains the same. The response includes state_proof and config_proof. First, deserialize the state_proof cell:
not runnable
To do this, verify the block header proof and store the new hash from the StateUpdate. Next, deserialize the config_proof cell:
not runnable
Compare the Hash_1 from the Merkle proof (reference only) with the hash obtained from the check_block_header function above. If they match, the cell can be trusted:
Next, deserialize the cell using the ShardStateUnsplit schema:
Then, access the ShardStateUnsplit -> custom -> config -> config field, a Hashmap where the key is a ConfigParam number and the value is a cell containing the parameter value. After deserializing all parameters, we obtain: