Skip to main content
To verify a trustpoint from Cert API, we have 3 ways to interact with the Blockchain network. As an example, we will use the certificate from the following image: cert For all verification methods, the certID, timestamp, and networkId fields will be used. Additionally, for methods 2 and 3, the smartContract field will also be used. All of them are highlighted in red in the image.

​
Method 1: Interact with the TrustOS API

This is the simplest and most direct method once the integration with TrustOS is done, and the one we recommend for most cases. Essentially, you need to call the following endpoint of the Cert API: For more detailed information on how to make this call, you can refer to the technical documentation of the endpoint.

​
Method 2: Interacting with the block explorer

This method depends on the existence of a block explorer that allows the query of the Blockchain where the trustpoint has been registered. To do this, you need the address of the Smart Contract where the trustpoint has been registered (field smartContract) and use the block explorer corresponding to the network that appears in the networkId field. In this link the Smart Contract is shown in the block explorer. Next, you need to access the contract tab and check the available functions. The function to call is getTrustPoint and the parameters to pass are the certID and the timestamp of the trustpoint you want to verify. Finally, run the function with the Query button and it will show the result, which matches the trustPointHash field of the trustpoint and its type (0 -> Evidence). Etherscan TrustPointRepo read functions

​
Method 3: Directly querying the Blockchain

In Blockchain networks, all information is pseudopublic since anyone can read it. To interact directly with the Blockchain, we will use what is known as the JSON-RPC API. This is a communication protocol that facilitates interaction with Blockchain networks based on the Ethereum client. To make this protocol work, you need the so-called JSON-RPC-ENDPOINT. This is the “gateway” to interact with the Blockchain and is nothing more than an open connection to a node running the Ethereum-based Blockchain client that we need. Thanks to this communication method, you can query information such as the Ethereum client implemented by the desired Blockchain, or even the networkId of the Blockchain. An example of a call for the latter would be: 
curl -X POST '<JSON-RPC-ENDPOINT>' \
	--data '{
		"jsonrpc":"2.0",
		"method":"net_version",
		"params":[],
		"id":67
}'
If we use a Polygon’s JSON-RPC-ENDPOINT, the response will be 137. 
{
	"jsonrpc":"2.0",
	"id":67,
	"result":"137"
}
Now, for the specific case of verifying a trustpoint registered using Cert API, the call that needs to be made is called eth_call, which executes a call to the Blockchain without creating a transaction. Since it is a read method, there will be no gas cost or network fees involved. The call would look like this: 
curl -X POST '<JSON-RPC-ENDPOINT>' \
	-H "Content-Type: application/json" \
	--data '{
		"jsonrpc": "2.0", 
		"method": "eth_call", 
		"params": [
			{
				"to": "<SMART_CONTRACT>", 
				"data": "<INFO>"
			},
			"latest"
		], 
		"id": 1
}'
The fields to fill in are as follows:
  • JSON-RPC-ENDPOINT
  • SMART_CONTRACT: Address of the Smart Contract where the trustpoint has been registered.
  • INFO: Hash of the function signature and the encoded parameters certID and timestamp.
To encode the parameters, you can use the following online tool, taking into account that the function of the Smart Contract to be called is: 
function getTrustPoint (string memory certId, uint256 timestamp) 
	public view returns (string memory, TrustPointType)
encoder configuration encoded parameters Once all the parameters are correctly encoded, the call looks like this: 
curl -X POST '<JSON-RPC-ENDPOINT>' \
	-H "Content-Type: application/json" \
	--data '{
		"jsonrpc": "2.0",
		"method": "eth_call", 
		"params": [
			{
				"to": "0x13f66aE1905dba6a05a3BE36fC79F30E6644657F",
				"data": "0x4a53265300000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000066a344ff000000000000000000000000000000000000000000000000000000000000004f6469643a6465763a6365727469643a343637663364633831633061303233333435633661336134313563363330343635306338643335333036306364313965363131663831323364353364366337630000000000000000000000000000000000"
			},
			"latest"
		], 
		"id": 1
}'
The response to this call, if done correctly, can be in 2 ways.
  • Trustpoint not found 
    {
	"jsonrpc": "2.0",
	"id": 1,
	"error": {
		"code": -32000,
		"message": "Execution reverted",
		"data": "0x16fd89cc"
	}
}
    The hexadecimal value 0x16fd89cc corresponds to the error returned by the Smart Contract when the trustpoint is not found. The parameters entered do not match the records stored in the Blockchain.
  • Trustpoint found 
    {
	"jsonrpc": "2.0",
	"id": 1,
	"result": "0x00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004036383265646166646435646339663034646161396665313631333863393534306130313630643066316464386637623461383732373534656630353564353761"
}
    The result, encoded, is the hash associated with that certID at that specific timestamp along with the type of trustpoint (Evidence -> 0, Revocation -> 1, Signature -> 2). To decode it, you can use the following online tool. decoder configuration decoded parameters As you can see, the first decoded parameter matches the hash of the certificate, ensuring the immutability of the information. For Revocation trustpoints, the first decoded parameter is the double hash of the string Certificate did:dev:certid:467f3dc81c0a023345c6a3a415c6304650c8d353060cd19e611f8123d53d6c7c has been revoked. Finally, for Signature trustpoints, the first decoded parameter corresponds to the double hash of the generated signature.
⌘I